Differences
This shows you the differences between two versions of the page.
Both sides previous revision
Previous revision
Next revision
|
Previous revision
Next revision
Both sides next revision
|
treex:api [2015/12/13 23:56] popel |
treex:api [2015/12/14 01:26] popel |
===== Mají children/descendants/siblings vracet setříděné uzly? ===== | ===== Mají children/descendants/siblings vracet setříděné uzly? ===== |
* Současné řešení vrací uzly v nedefinovaném pořadí (u descendant průchodem do hloubky, děti pak v pořadí vložení), takže když chci pořadí dle (povrchového) slovosledu, musím zavolat ''get_children({ordered=>1})''. To je dost nešikovné, protože na to člověk často zapomene, na většině vět to funguje (pořadí dle vložení se většinou shoduje se slovosledným), ale pak ne a těžko se to debugguje. | * Současné řešení vrací uzly v nedefinovaném pořadí (u descendant průchodem do hloubky, děti pak v pořadí vložení), takže když chci pořadí dle (povrchového) slovosledu, musím zavolat ''get_children({ordered=>1})''. To je dost nešikovné, protože na to člověk často zapomene, na většině vět to funguje (pořadí dle vložení se většinou shoduje se slovosledným), ale pak ne a těžko se to debugguje. |
| * V současných zdrojácích bloků Treexu je 909 volání ''get_descendants'' a 405 z nich je ''ordered'' (jak často se které volání používá teď neberu v potaz). Navíc 455 bloků používá ''process_[at]node'', která vyžaduje ''get_descendants({ordered=>1})''. U ''get_children'' je to ordered/vše=95/598 a u ''get_siblings'' 2/46. Závěr: setřídění uzlů je potřeba velmi často (byť někde mohlo být to ordered přidáno preventivně a vlastně to potřeba není, viz předchozí bod). |
| * Ve zdrojácích je 241 volání metod ''shift_(before|after)_(node|subtree)''. Část z toho je volání hned po přidání nového uzlu. Změna slovosledu je tedy častá. Mám ale pocit, že v typickém scénáři (t-analýza, překlad) se mění slovosled mnohem méně často, než jak často se přistupuje k setříděným dětem/potomkům (chtělo by to profiling pro přesná čísla). |
| * U ''children'' a ''siblings'' by rozumná implementace měla udržovat seznam pořád setříděný (teď se pokaždé volá ''sort''), takže by parametr ''ordered'' mohl z API zmizet. |
| * U ''descendants'' je situace složitější, protože u neprojektivních stromů nejde správné pořadí potomků získat průchodem do hloubky. Viz [[treex:api-implementation#setrideni-dle-ord|poznámky k implementaci setřídění]]. |