| Both sides previous revision
Previous revision
Next revision
|
Previous revision
|
treex:api [2015/12/13 23:56]
popel |
treex:api [2015/12/14 18:12] (current)
popel |
| create_child | create_child |
| get_parent -> parent | get_parent -> parent |
| set_parent | set_parent (defaultně kontroluje, aby nevznikl cyklus) |
| get_children | get_children |
| | |
| | === Word-order methods === |
| | precedes($another_node) |
| | get_next_node -> next_node() |
| | get_prev_node -> prev_node() |
| | shift_after_node($reference_node, {without_children=>1}) |
| | shift_after_subtree($reference_node, {without_children=>1}) |
| | shift_before_node($reference_node, {without_children=>1}) |
| | shift_before_subtree($reference_node, {without_children=>1}) |
| | is_nonprojective($reference_node, {without_children=>1}) |
| |
| === New methods === | === New methods === |
| ===== 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í]]. |
