[ Skip to the content ]

Institute of Formal and Applied Linguistics Wiki

• ÚFAL Wiki Home
• ÚFAL Home
• Sitemap
• RSS
• ÚFAL calendar
• Recent changes
• Login
• Hledat:

[ Back to the navigation ]

Differences

This shows you the differences between two versions of the page.

View differences: Side by SideInline Go

Link to this comparison view

Both sides previous revision Previous revision 2016/01/08 23:17 popel 2016/01/08 19:27 popel 2016/01/08 19:03 popel 2016/01/08 18:28 popel 2016/01/08 17:29 popel 2016/01/08 14:48 popel 2016/01/08 00:09 popel 2016/01/07 18:02 popel 2015/12/15 16:25 popel 2015/12/14 11:18 popel 2015/12/14 03:43 popel 2015/12/14 01:26 popel 2015/12/11 13:35 ufal 2015/12/11 13:34 ufal 2015/12/11 12:51 popel 2015/12/11 12:29 popel 2015/12/11 11:16 popel 2015/12/11 11:14 popel 2015/12/11 11:12 popel 2015/12/11 11:09 popel 2015/12/11 11:06 popel 2015/12/11 10:31 popel 2015/12/11 10:13 popel 2015/12/10 18:41 popel 2015/12/09 15:04 popel 2015/12/08 21:32 popel 2015/12/08 21:31 popel 2015/12/08 17:52 popel created Go		2016/01/08 23:17 popel 2016/01/08 19:27 popel 2016/01/08 19:03 popel 2016/01/08 18:28 popel 2016/01/08 17:29 popel 2016/01/08 14:48 popel 2016/01/08 00:09 popel 2016/01/07 18:02 popel 2015/12/15 16:25 popel 2015/12/14 11:18 popel 2015/12/14 03:43 popel 2015/12/14 01:26 popel 2015/12/11 13:35 ufal 2015/12/11 13:34 ufal 2015/12/11 12:51 popel 2015/12/11 12:29 popel 2015/12/11 11:16 popel 2015/12/11 11:14 popel 2015/12/11 11:12 popel 2015/12/11 11:09 popel 2015/12/11 11:06 popel 2015/12/11 10:31 popel 2015/12/11 10:13 popel 2015/12/10 18:41 popel 2015/12/09 15:04 popel 2015/12/08 21:32 popel 2015/12/08 21:31 popel 2015/12/08 17:52 popel created Go Next revision Both sides next revision
treex:api-implementation [2015/12/14 11:18] popel		treex:api-implementation [2015/12/15 16:25] popel
Line 162:		Line 162:
	Metoda ''descendants'' tedy začne nejlevějším a iteruje až do nejpravějšího (a vynechá uzel, ze kterého to volám, pokud není ''add_self'').		Metoda ''descendants'' tedy začne nejlevějším a iteruje až do nejpravějšího (a vynechá uzel, ze kterého to volám, pokud není ''add_self'').
	Problém je jen s neprojektivitami, takovéto uzly musím přeskočit. Každý uzel má tedy seznam (spoják) uzlů, v jejichž spanu (leftmost..rightmost) se slovosledně nachází a přitom není jejich potomkem. Většina uzlů je projektivních a má tedy tento seznam prázdný, takže při iteraci mám jen jeden if navíc. Zatím se mi tato implementace líbí nejvíc.		Problém je jen s neprojektivitami, takovéto uzly musím přeskočit. Každý uzel má tedy seznam (spoják) uzlů, v jejichž spanu (leftmost..rightmost) se slovosledně nachází a přitom není jejich potomkem. Většina uzlů je projektivních a má tedy tento seznam prázdný, takže při iteraci mám jen jeden if navíc. Zatím se mi tato implementace líbí nejvíc.
		+
		+	Vylepšení1:
		+	Při zavolání z kořene stromu by se vrátil speciální iterátor, který vůbec nekontroluje seznamy neprojektivit (takže se ušetří to if, ale hlavně procházení všech seznamů). Toto vylepšení mi přijde zcela jasně přínosné.
		+
		+	Vylepšení2:
		+	V seznamech neprojektivit budou uzly setříděné vzestupně dle hloubky. Jakmile narazím na uzel s vyšší hloubkou než uzel, který testuji (ze kterého jsou ''descendants'' zavolané), tak skončím a neprocházím zbytek seznamu. Zde si vůbec nejsem jist, zda to má cenu, protože sice ušetřím procházení části seznamu u některých uzlů, jenže zase přibude testování hloubky (kterou bych musel mít v tom seznamu asi předpočítanou, a tedy ji aktualizovat, když se změní).
	Alternativa: atribut _leftmost (a obdobně _rightmost) by se vyplňoval pouze tehdy, pokud by se sledováním nejlevějšího dítěte nedalo dostat do nejlevějšího potomka. Tedy v projektivních stromech by se ty atributy nemusely vyplňovat vůbec (vůbec by nezabíraly místo v hash-based objektech). Editace by pak mohly být o něco rychlejší, pokud detekuji, že projektivní strom měním na projektivní. Čtení ale bude pomalejší, protože budu muset iterovat do těch nejlevějších dětí (a ještě navíc testovat, zda není v uzlech vyplněn _leftmost).		Alternativa: atribut _leftmost (a obdobně _rightmost) by se vyplňoval pouze tehdy, pokud by se sledováním nejlevějšího dítěte nedalo dostat do nejlevějšího potomka. Tedy v projektivních stromech by se ty atributy nemusely vyplňovat vůbec (vůbec by nezabíraly místo v hash-based objektech). Editace by pak mohly být o něco rychlejší, pokud detekuji, že projektivní strom měním na projektivní. Čtení ale bude pomalejší, protože budu muset iterovat do těch nejlevějších dětí (a ještě navíc testovat, zda není v uzlech vyplněn _leftmost).

---

[ Back to the navigation ] [ Back to the content ]