zaznam.txt


*******************************************************************************
Perlový parser - záznam pokusů
*******************************************************************************



16.1.2002

Zkopíroval jsem si část "am" z PDT verze 1. Tuto část budu nyní
používat pro trénování. Obsahuje 83197 vět. Morfologická anotace je
provedena statisticky, morfologická analýza chybí, ale dá se snad
doplnit. Syntaktická anotace je ruční.



17.1.2002

První měření na nových trénovacích datech, ještě však se starými
(baltimorskými) testovacími daty. Nový model je zatím výhradně
lexikální (tj. funguje na slovních tvarech) a nebere v úvahu
závislosti, které byly při tréninku vidět jenom jednou (tj. co bylo
vidět jednou, jako by nebylo vidět vůbec - šetří se tím paměť a čas).
Model také zatím nemá žádné finesy, které jsem dříve doplňoval do
modelu na značkách, s výjimkou projektivity. Chybí tedy podpůrný model
pro plodnost slova, směr závislosti i vzdálenost členů
závislosti. Také chybí Viterbi, tj. strom se buduje hladovou (ale
komponentovou) metodou.

G 28685 - B 35019 - P 45,0

Přidán směr hrany.

G 26955 - B 36749 - P 42,3

Ponechány i záznamy o hranách spatřených jen jednou.

G 43000 - B 20704 - P 67,5

Přidána "vzdálenost" (sousední = B, blízko; nesousední = D, daleko).

G 44671 - B 19033 - P 70,1

Přechod na testovací data z PDT1 (lu, lv, lw). Úspěšnost klesla skoro
na polovinu, což je dost zarážející, možná je chyba ve vyhodnocování
(nebo byla před chvílí).

G 49157 - B 77450 - P 38,8



18.1.2002

Po nalezení a odstranění chyby ve skriptu se úspěšnost vrátila už jen
na 42 %. Závratné výsledky u starých dat byly zřejmě způsobeny tím, že
stará testovací data jsou nyní součástí nových trénovacích.

G 53217 - B 73390 - P 42,0

Z trénovacích i testovacích dat odstraněna velká písmena, zbytečně
štěpila statistiky.

G 54027 - B 72580 - P 42,7

Ještě jeden pokus zahodit závislosti, které byly vidět jenom jednou.

G 50365 - B 76242 - P 39,8

Vráceny závislosti viděné jen jednou, přidán model pro plodnost uzlu.

G 54421 - B 72186 - P 43,0

Odstraněna chyba, že některé věty obsahovaly slovo "konec
řádku". Úspěšnost klesla, protože chyba uměle přidávala neexistující
věty, které se nedaly zkazit.

G 53982 - B 72046 - P 42,8

Pokus s modelem na značkách (od taggeru). Zatím neredukovaná sada
značek a bez Viterbiho, takže pokud se výsledky podobají těm z
Baltimoru, je to komponentovým budováním stromu a zejména větším
objemem trénovacích dat a snadněji analyzovatelnými testovacími daty.

G 71535 - B 54493 - P 56,8

Redukované značky: to snad ani za tu námahu nestojí! Že by zase bug?

G 71622 - B 54406 - P 56,8

Značky redukované podle Collinse: u značek, které mají pád (N, A, P, C
a R), slovní druh a pád, u ostatních slovní druh a poddruh.

G 72207 - B 53821 - P 57,3

Po načtení statistik pro slova i značky úspěšnost kupodivu mírně
stoupla, byť se ve statistikách nadále hledaly jen značky. Možná
proto, že některá slova jsou shodná s některými značkami a náhodou to
vyšlo?

G 72364 - B 53664 - P 57,4



První kombinace modelu na slovech s modelem na značkách! Značkový
model se použije tehdy, když slovní doporučuje závislost, kterou nikdy
neviděl. Jinak se dá vždy přednost slovnímu modelu.

G 71445 - B 54583 - P 56,7

Při nahrazování slovních hran, které byly vidět nejvýše jednou:

G 72593 - B 53435 - P 57,6

Při nahrazování slovních hran, které byly vidět nejvýše dvakrát:

G 72327 - B 53701 - P 57,4



-------------------------------------------------------------------------------
Rokytnice nad Jizerou
Pozor, tento týden pokusy nejsou na stejných trénovacích ani
testovacích datech, protože je dělám na notebooku a ten neutáhne
příliš velká data. Ani během toho týdne nejsou bohužel data pořád
stejná.



21.1.2002

V následujících testech se přednostně používaly statistiky na slovech,
pokud byla četnost 0, 1 nebo 2, použila se místo toho statistika na
značkách. Pokud se tedy dále mluví o četnosti, je to buď četnost na
slovech, nebo na značkách, podle toho, jak se výpočet odvíjel.
924 slov celkem
Při použití všech hran bez ohledu na četnost:
G 605 - B 319 - UG 0 - UB 0 - P 65,5 % - R 65,5 %
Při vynechání hran s četností 0:
G 582 - B 279 - UG 23 - UB 40 - P 67,6 % - R 63,0 %
Při vynechání hran s četností menší než 2:
G 439 - B 168 - UG 166 - UB 151 - P 72,3 % - R 47,5 %
Při vynechání hran s četností menší než 3:
G 354 - B 112 - UG 251 - UB 207 - P 76,0 % - R 38,3 %
Při vynechání hran s četností menší než 4:
G 283 - B 68 - UG 322 - UB 251 - P 80,6 % - R 30,6 %
Při vynechání hran s četností menší než 5:
G 244 - B 59 - UG 361 - UB 260 - P 80,5 % - R 26,4 %



22.1.2002

Nevynechávají se žádná slova. V kolech, ve kterých vyhrála závislost se
slovní pravděpodobností menší než 5, se hledání opakuje s použitím
pravděpodobnosti složené ze slovní a značkové pravděpodobnosti, přičemž
obě mají stejnou váhu 0,5.

G 692 - B 232 - P 74,9

Dotaz: Najít případy, kdy na základě slovní pravděpodobnosti vyhrála
špatná závislost, ale s použitím pravděpodobnosti na dvojicích (heslo,
značka) by vyhrála správná závislost.

K tomu je nutné natrénovat model na dvojicích (heslo, značka). Jsou dvě
možnosti, jak takový model definovat ale jen ta druhá má smysl; ta první
je téměř ekvivalentní modelu na slovech:

P = P((heslo1, značka1) - (heslo2, značka2)) = P(slovo1 - slovo2)
nebo
P = P(heslo1 - heslo2) * P(značka1 - značka2)



23.1.2002

Přepsány kusy train.pl i parse.pl, aby se oba programy daly rozšiřovat
o různé modely. Nyní je potřeba je vyladit, protože kvůli nějakým chybám
úspěšnost zase hluboko klesla.

1. Model slovních, heslových a značkových závislostí přetrénován na balíku
Lidových novin. 865 souborů, 45091 vět, 698671 slov (bez kořenů). Klářin
notebook trénuje rychlostí zhruba 1000 vět za 50 vteřin (zpočátku). Ale
limit, než notebook upadne do nekonečného swapování, je asi 6000 vět.
Nakonec vzat výsledek trénování podle prvních 5000 vět. Nalezeno 57036
různých závislostí slov, 51328 různých závislostí hesel a 2681 různých
závislostí značek.



24.1.2002

Začínám testovat včera natrénovaný model. Testovací data velká a malá
(kvůli rychlosti). Malá data: lu02.a (53 vět, 924 slov bez kořenů).
Velká data: test.a = sřetězení lu02.a až lu05.a (216 věž, 3540 slov bez
kořenů).

Samotný model závislostí značek bez modelu plodnosti. Výsledky v prvním
řádku platí při použití všech hran včetně těch, které nebyly v trénovacích
datech vidět nikdy (tj. čirý odhad). Údaje ve druhém řádku takové závislosti
vynechávají.

G 510 - B 414 - P 55,2
G 488 - B 385 - P 55,9 - R 52,8

Model závislostí značek včetně plodnosti (ale bez závislostí slov).

G 519 - B 405 - P 56,2
G 499 - B 375 - P 57,1 - R 54,0

Model závislostí slov bez plodnosti. Těch 53 vět trvá na Klářině notebooku
11 minut, z toho 5 minut načítání statistik!

G 315 - B 609 - P 34,1
G 174 - B 228 - P 43,3 - R 18,8

Totéž, ale s plodností.

G 313 - B 611 - P 33,9
G 173 - B 229 - P 43,0 - R 18,7

Kombinace slovního a značkového modelu. Slovní závislosti viděné alespoň
pětkrát se použijí bez ohledu na plodnost. Jinak se zkombinují se značkovými
půl na půl (je už nutné normalizovat četnosti, aby se z nich staly pravděpodobnosti,
ale dřív jsem to nedělal a fungovalo to, tak raději vyzkoušíme obojí).
Celková četnost se násobí značkovou plodností, žádná slovní plodnost se
nevyužívá.

G 524 - B 400 - P 56,7
G 515 - B 379 - P 57,6 - R 55,7

Druhý pokus: od předchozího se liší pouze tím, že absolutní četnosti jsou
převedeny na relativní, tj. na pravděpodobnosti.

G 524 - B 400 - P 56,7
G 515 - B 379 - P 57,6 - R 55,7

Ještě jeden nápad: Nekombinovat slova a značky půl na půl, ale v opačném
poměru, než v jakém jsou jejich průměrné četnosti - aby se slova měla
vůbec šanci prosadit. Nebo v poměru "kolik je různých závislostí slov"
proti "kolik je různých značek".

G 525 - B 399 - P 56,8
G 516 - B 378 - P 57,7 - R 55,8



-------------------------------------------------------------------------------
Praha
Zpátky z Rokytnice nad Jizerou, nejdřív se pokusím přesně zopakovat
výsledky z Rokytnice (na stejných datech).



30.1.2002

Stejná trénovací i testovací data jako v Rokytnici, stejné výsledky -
to se mi ulevilo.

G 525 - B 399 - P 56,8
G 516 - B 378 - P 57,7 - R 55,8

Tohle je bez vyhlazení plodnosti a na rokytnických trénovacích datech
(prvních 5000 vět z Lidových novin), ale na kompletních testovacích
datech (samé Lidové noviny).

G 72227 - B 53801 - P 57,3
G 69951 - B 51605 - P 57,5 - R 55,5

A teď ještě opačný pokus: rokytnická testovací data (tj. pouze
lu02.a), ale všechna trénovací data (přes 80000 vět).

G 546 - B 378 - P 59,1
G 542 - B 367 - P 59,6 - R 58,7

Na závěr dne: rokytnické programy, ale kompletní trénovací i testovací
data z PDT 1.

G 72749 - B 53279 - P 57,7
G 71792 - B 52300 - P 57,9 - R 57,0



31.1.2002

Vyhlazení plodnosti. Pokud c(uzel)<5, dá se místo všech nulových plodností
malé číslo, které je menší než nejmenší skutečná plodnost daného uzlu, celek
se pak normalizuje na součet 1. U uzlů, které byly vidět častěji, se nuly
ponechávají, protože se považují za dostatečně prokázané. Pseudokód pro
řídce pozorované uzly:
fmin = min(f(uzel, i), i);
n0 = count(f(uzel, i)==0);
foreach i where f(uzel, i)==0 {f(uzel, i) = 0.5*fmin/n0;}
for i = 0 to 3 {f(uzel, i) /= (1+0.5*fmin);}

G 72749 - B 53279 - P 57,7
G 71792 - B 52300 - P 57,9 - R 57,0

To je dost divné, že by tato změna neudělala s výsledky vůbec nic?
Nejspíš je to tím, že momentálně používám jen značkovou plodnost a tam
se asi nuly příliš nevyskytují.

Zkusíme se tedy ještě vrátit ke slovní plodnosti, teď už
vyhlazené. Celková plodnost bude součin slovní a značkové plodnosti.

G 72510 - B 53518 - P 57,5
G 72095 - B 53024 - P 57,6 - R 57,2

Pokus: adaptivní analýza. Po výběru závislosti se tato přidá do
statistiky a od příště se může použít, jako by byla viděna v
trénovacích datech.

G 71304 - B 54724 - P 56,6
G 71299 - B 54702 - P 56,6 - R 56,6

Je to zhoršení, takže se vrátíme k původnímu stavu. Chyb při analýze
je ještě příliš mnoho, než aby bylo dobré se z analýzy něco učit.



1.2.2002

Opět zrušit adaptivní analýzu a taky slovní plodnost.

Pokus o demagnetizaci souřadících spojek. Pokud se to podaří, bude
ještě potřeba demagnetizovat dvojkříž v kořeni, čárky (fungují jako
spojky) a možná i něco dalšího.

První způsob demagnetizace: spojka a poslední člen koordinace se
prohodí, ostatní členy koordinace a čárky tedy závisejí na posledním
členu. Testování je zatím tím méně čestným způsobem, tj. koordinace ve
vzorové analýze se transformují podobně jako se transformovaly v
trénovacích datech. Čestnější by bylo provést inverzní transformaci
nalezené analýzy a výsledek porovnat s netransformovanou vzorovou
analýzou. Může se totiž stát, že transformace nějakou informaci
ztratí, a pak oba postupy nebudou ekvivalentní.

I tak je ovšem výsledek katastrofální. Z mě neznámých příčin
transformace koordinací mimořádně zvýšily přitažlivost kořenů vět.

G 40659 - B 85369 - P 32,3
G 40656 - B 85353 - P 32,3 - R 32,3

Byla nějaká bota v plodnosti. Zatím plodnost odstavena úplně, ale
lepší výsledky asi budou, až chybu odstraníme a plodnost znovu
použijeme.

G 75578 - B 50450 - P 60,0
G 75577 - B 50441 - P 60,0 - R 60,0



7.2.2002

Odstraněna chyba v plodnosti. Bohužel se ukazuje, že ani tak není
plodnost v tomto tvaru přínosem.

G 73320 - B 52708 - P 58,2
G 72823 - B 52255 - P 58,2 - R 57,8

Plodnost tedy vyřazena z činnosti. Pro kontrolu ještě jednou test, měl
by mít stejné výsledky jako poslední test z 1. února, ale není tomu
tak. Výše zmíněná chyba (způsobená mimochodem už při trénování, kdy se
dvojkříž z kořene nahrazoval prázdným řetězcem) měla zřejmě při
vynechání plodnosti blahodárné účinky. Nicméně i tohle je zlepšení
oproti původním koordinacím o 0,6 %.

G 73427 - B 52601 - P 58,3
G 72985 - B 52059 - P 58,4 - R 57,9

Druhý způsob demagnetizace koordinačních spojek. Kořenem podstromu je
poslední člen koordinace, na každém členu koordinace vždy visí
předcházející člen a čárka nebo spojka, která ho od předcházejícího
členu odděluje.

G 74611 - B 51417 - P 59,2
G 74168 - B 50887 - P 59,3 - R 58,9

Třetí způsob demagnetizace koordinačních spojek. Kořenem podstromu je
poslední člen koordinace, na něm visí koordinační spojka, na ní
předcházející člen koordinace, na něm popř. čárka, pak další člen atd.
---
Objevena chyba v transformacích koordinací. Po opravě chyby nové
pokusy.

První způsob (pouze výměna kořene):

G 73943 - B 52085 - P 58,7
G 73464 - B 51538 - P 58,8 - R 58,3

Druhý způsob (binární stromeček):

G 74398 - B 51630 - P 59,0
G 73919 - B 51084 - P 59,1 - R 58,7

Třetí způsob (řetízek):

G 73059 - B 52969 - P 58,0
G 72681 - B 52474 - P 58,1 - R 57,7



8.2.2002

Velmi často se chybuje v tečce za větou. Dostane se na řadu až příliš
pozdě, takže po ní dříve než kořen hmátne nějaké slovo věty. Dvě možná
řešení. První: je-li na konci věty interpunkce, hned na začátku ji
pověsit pod kořen. Druhé - statisticky čistší, ale předpokládám menší
úspěšnost: do povolených hran přidat hranu z kořene do posledního
dosud nezavěšeného slova věty - vzhledem k tomu, že nepovolujeme
zavěsit kořen pod něco jiného, projektivita se tím neporuší. Možná, že
dokonce můžeme povolit hranu z kořene kamkoliv, ale tím si nejsem
jistý. Zatím zkusím nejjednodušší cestu, tj. první řešení.

G 78156 - B 47872 - P 62,0
G 77975 - B 47735 - P 62,0 - R 61,9

Další problém je se složenými předložkami (např. "v oboru"). I na ně
zavedeme transformaci a budeme je testovat "nečestným způsobem",
tj. tutéž transformaci provedeme s testovacími daty, místo abychom
inverzní transformaci prováděli s výsledkem analýzy. Výsledkem je
kupodivu zhoršení. Raději tuto transformaci zrušíme.

G 77619 - B 48409 - P 61,6
G 77440 - B 48283 - P 61,6 - R 61,4

Upravena Mikova redukce značek. U interpunkce přidáno jako druhý znak
znaménko samo.

G 79364 - B 46664 - P 63,0
G 79153 - B 46359 - P 63,0 - R 62,8

Rozštěpena statistika o závislostech na kořeni. Místo na směr (který
je od kořene vždy doprava) se ptáme, zda věta obsahuje nebo neobsahuje
sloveso. Pokud ho totiž obsahuje, visí na kořeni obvykle ono,
popřípadě šéf koordinace, jehož je členem, ale ne jiné slovní druhy.

G 79572 - B 46456 - P 63,1
G 78634 - B 44988 - P 63,6 - R 62,4

Nečekaným důsledkem je velmi časté chybné připojení slovesa na
koncovou interpunkci místo na kořen. Proto ještě rozšíříme úpravu sady
značek: pokud jde o poslední prvek věty, připojí se na konec značky
"K", celá značka tedy bude např. "Z.K".

G 81727 - B 44301 - P 64,8
G 78618 - B 40262 - P 66,1 - R 62,4

Úspěšnost sice stoupla, ale na příkladech chybných vět je vidět, že
v místech, kvůli kterým jsem k poslednímu opatření sáhl, se toto
minulo účinkem. Bude nutné ještě totéž co se značkou provést s heslem
a se slovem.

G 81901 - B 44127 - P 65,0
G 78624 - B 40100 - P 66,2 - R 62,4

Navzdory vší snaze ukázky chyb i nadále ukazují řadu závislostí vedoucích
koncové interpunkce dolů, takže bychom je možná mohli zakázat natvrdo. Efekt
ale zpočátku asi nebude velký, protože ve stejném souboru chyb je vidět, že
kořen podstromu pod interpunkcí je stejně nějaký nesmysl, který kořenem být
nemá, takže zavěšením celého podstromu jinam se chyba neodstraní. Asi je
nejvyšší čas vrátit Viterbiho.



9.2.2002

Intermezzo - pokusy doma na menších trénovacích i testovacích datech! Ke
trénování použity soubory začínající na "c1", k testování pouze soubor "l02.a".
Testujeme algoritmus Viterbiho, takže nám zmizelo průběžné sledování, co by se
stalo, kdybychom vynechávali závislosti s nulovou četností. (Stejně už se to
delší dobu moc neliší.) Nicméně zatím testujeme jen funkčnost, takže šířka
Viterbiho je nastavena na 1. Výsledek by tedy měl být stejný jako dříve, což
ještě pro jistotu ověříme později na fakultě. POZOR (do přednášky)! Viterbi
vyžaduje alespoň primitivní vyhlazení, nuly ho dokážou úplně zničit!

G 629 - B 383 - P 62,2 - T 0:20 s



10.2.2002

Ale totéž starým programem dává jiné výsledky!

G 590 - B 334 - P 63,9 - T 0:16 s
G 569 - B 301 - P 65,4 - R 61,6

U Viterbiho vychází celkem 1012 závislostí, v původní proceduře 924 (což je
číslo, se kterým se setkávám už dlouho, takže mu věřím spíš).

Přestávám porovnávat kořen (to jsou samé chyby), stejně ale nedostávám součet,
jaký má být. Úspěšnost je ovšem teď zas lepší než původně.

G 629 - B 335 - P 65,2

Objevena další chyba - zavěšení koncové interpunkce se započítávalo dvakrát.
Nyní už výsledky Viterbi(1) vypadají stejně jako výsledky původní procedury:

G 590 - B 334 - P 63,9

Viterbi(2)

G 563 - B 361 - P 60,9

Viterbi(2) se započítáním obou nejlepších stromů:

G 1091 - B 694 - P 61,1

Objevena další chyba - kořen neměl značku #, nýbrž prázdný řetězec. Oprava ale
výsledky vylepšit nedokázala.

G 590 - B 334 - P 63,9

Objevena další chyba - hrany se dělily podle směru i u kořene, přestože tam je
směr vždy doprava a místo směru se mělo sledovat, zda věta obsahuje sloveso.

G 595 - B 329 - P 64,4
G 594 - B 325 - P 64,6 - R 64,3

Totéž s viterbim(2), započítávají se oba nejlepší stromy:

G 826 - B 501 - P 62,2

A teď se asi definitivně vrátíme k analýze bez Viterbiho (resp. k Viterbimu
s paprskem šířky 1). Nicméně budeme nadále pracovat s programem, který
Viterbiho na požádání umožňuje. Starý program od této chvíle přestávám
aktualizovat.

G 595 - B 329 - P 64,4

U značkového modelu nyní k předložkám místo pádu dávám přímo předložku samu.
Bráním se tím zbytečným chybám způsobeným mylným výstupem Honzova taggeru.

G 596 - B 328 - P 64,5

Do vzdálenosti přidán třetí stav. Kromě B (blízko, tj. sousedi) a D (daleko,
tj. nesousedi) ještě zvláštní druh D, označený čárkou (",") a znamenající, že
mezi dotyčnými se vyskytla čárka. První výsledky jsem pořídil omylem - model
byl už natrénován se třemi stavy, ale použit stále jen se dvěma. Jsem zvědavý,
jestli po opravě dojde k dalšímu zlepšení, nebo naopak ke zhoršení...

G 611 - B 313 - P 66,1

Po opravě skutečně trochu ztrácím, naštěstí ne až na původní úroveň:

G 607 - B 317 - P 65,7

Model vzdálenosti ještě rozšířen, nyní je evidován i počet čárek, které se mezi
uzly vměstnaly. Tím by se mohly spravit vícečlenné koordinace.

G 612 - B 312 - P 66,2



11.2.2002

Přeneseno zpátky na fakultu. Natrénováno opět na 83000 vět, testováno
na 7319 větách. Jinak vnitřně shodné. Výsledky jsou mírným zlepšením
oproti stavu na fakultě v pátek večer, ale zhoršením oproti stavu
včera večer doma.

G 82312 - B 43818 - P 65,3 - T 5:28

Pro jistotu zkusíme ještě jednou Viterbiho. Žádné překvapení se
bohužel nekoná :-(

G 93253 - B 51820 - P 64,3 - T 25:32

Pokusil jsem se, aby se stejně jako u analýzy ani u tréninku už
nevynechávala poslední věta. Protože jsem však přidal podmínku, že se
zpracovávají jen neprázdné věty, celkový počet ve skutečnosti klesl, a
to o dost: na 73088. Trénování trvalo něco přes 2:49 minuty. Počet
testovacích vět zůstává 7319.

G 82312 - B 43818 - P 65,3

Do značky pro podstatné jméno jsem přidal údaj, zda jde o křestní
jméno osoby (s dvojicí křestní jméno - příjmení se zachází jinak než s
jinou podobnou dvojicí podstatných jmen a bývají v tom chyby - snad
tato evidence pomůže)...

G 82948 - B 43257 - P 65,7

Malá statistika navíc:
34717 případů rozhodoval pouze značkový model (slovní p=0).
      To je 27,5 % ze 126205 celkem rozhodovaných slov.
      Tyto případy dopadly G 20681 - B 14036 - P 59,6.
100 % správných vět bylo 867, tj. asi 11,8 %.
      Nejdelší z nich měla 18 (!) slov.
      Průměrně takové věty měly 4 slova.
      Průměrná délka testovací věty je přitom 17 slov.
      Možná by bylo zajímavé odvodit statistiku, která by kromě
      úspěšnosti na závislostech také měřila, jak těžké bylo této
      úspěšnosti dosáhnout - na větách o 1 slovu to bylo jednoduché,
      na větách o 100 slovech je i 50 % velký úspěch - možná větší,
      než odpovídá 50 zavěšeným slovům?



První pokus s modelem závislostí hesel. Samostatně testujeme model
"hesla*znacky", tj. pravděpodobnost, že se současně vyskytla daná
závislost mezi hesly a daná závislost mezi značkami. (To není totéž
jako pravděpodobnost, že se vyskytla závislost, jejíž řídící uzel má
současně dané heslo1 a značku1 a závislý uzel má současně dané heslo2
a značku2. Tato druhá možnost je téměř ekvivalentní modelu závislostí
slov, zatímco první možnost je méně specificky parametrizována.

"slova"
A 126030 - G 54684 - B 71346 - P 43,4 (vse)
A  40496 - G 22634 - B 17862 - P 55,9 (>=5)
A  29997 - G 15635 - B 14362 - P 52,1 (>=1)
A  55537 - G 16415 - B 39122 - P 29,6 (==0)

"hesla"
A 126030 - G 46360 - B 79670 - P 36,8 (vse)
A  44601 - G 20362 - B 24239 - P 45,7 (>=5)
A  21059 - G  8002 - B 13057 - P 38,0 (>=1)
A  60370 - G 17996 - B 42374 - P 29,8 (==0)

"znacky"
A 126030 - G 85215 - B 40815 - P 67,6 (vse) <== NEJLEPSI!!!
A 119222 - G 78586 - B 40636 - P 65,9 (>=5)
A    210 - G    79 - B   131 - P 37,6 (>=1)
A   6598 - G  6550 - B    48 - P 99,3 (==0) - ze by tohle byly Z.K?

"0.5*slova+0.5*znacky" (resp. "$ls*slova+$lz*znacky")
A 126030 - G 84264 - B 41766 - P 66,9 (vse)
A 111976 - G 74632 - B 37344 - P 66,6 (>=5)
A   7444 - G  3081 - B  4363 - P 41,4 (>=1)
A   6610 - G  6551 - B    59 - P 99,1 (==0)

pro >=5 "slova", jinak "0.5*slova+0.5*znacky"
A 126030 - G 82487 - B 43543 - P 65,5 (vse)
A 111734 - G 72799 - B 38935 - P 65,2 (>=5)
A   7680 - G  3135 - B  4545 - P 40,8 (>=1)
A   6616 - G  6553 - B    63 - P 99,0 (==0)

pro >=15 "slova", jinak "0.5*slova+0.5*znacky"
A 126030 - G 84089 - B 41941 - P 66,7 (vse)
A 119175 - G 77448 - B 41727 - P 65,0 (>=5)
A    244 - G    89 - B   155 - P 36,5 (>=1)
A   6611 - G  6552 - B    59 - P 99,1 (==0)

"hesla*znacky"
A 126030 - G 47558 - B 78472 - P 37,7 (vse)
A  63766 - G 29378 - B 34388 - P 46,1 (>=5)
A   1289 - G    39 - B  1250 - P  3,0 (>=1)
A  60975 - G 18141 - B 42834 - P 29,8 (==0)

"slovo-znacka"
A 126030 - G 46213 - B 79817 - P 36,7 (vse)
A 109476 - G 37433 - B 72043 - P 34,2 (>=5)
A   8915 - G  2083 - B  6832 - P 23,4 (>=1)
A   7639 - G  6697 - B   942 - P 87,7 (==0)

"heslo-znacka"
A 126030 - G 44212 - B 81818 - P 35,1 (vse)
A 111258 - G 36476 - B 74782 - P 32,8 (>=5)
A   7092 - G  1044 - B  6048 - P 14,7 (>=1)
A   7680 - G  6692 - B   988 - P 87,1 (==0)

"(heslo-znacka)*znacky"
A 126030 - G 54773 - B 71257 - P 43,5 (vse)
A  21132 - G 14391 - B  6741 - P 68,1 (>=5)
A  97168 - G 33680 - B 63488 - P 34,7 (>=1)
A   7730 - G  6702 - B  1028 - P 86,7 (==0)

pro >=5 "(heslo-znacka)*znacky", jinak "znacky"
A 126030 - G 85101 - B 40929 - P 67,5 (vse)
A 119222 - G 78472 - B 40750 - P 65,8 (>=5)
A    210 - G    79 - B   131 - P 37,6 (>=1)
A   6598 - G  6550 - B    48 - P 99,3 (==0)



12.2.2002

Hledáme nejlepší vyvážení modelů "slova" a "značky".
"ls*slova+lz*znacky"

ls=0
A 126030 - G 85215 - B 40815 - P 67,6 (vse)
A 119222 - G 78586 - B 40636 - P 65,9 (>=5)
A    210 - G    79 - B   131 - P 37,6 (>=1)
A   6598 - G  6550 - B    48 - P 99,3 (==0)

ls=0,25
A 126030 - G 85150 - B 40880 - P 67,6 (vse)
A 119151 - G 78493 - B 40658 - P 65,9 (>=5)
A    281 - G   107 - B   174 - P 38,1 (>=1)
A   6598 - G  6550 - B    48 - P 99,3 (==0)

ls=0,5
A 126030 - G 85262 - B 40768 - P 67,7 (vse)
A 119052 - G 78569 - B 40483 - P 66,0 (>=5)
A    376 - G   143 - B   233 - P 38,0 (>=1)
A   6602 - G  6550 - B    52 - P 99,2 (==0)

ls=0,5625
A 126030 - G 85265 - B 40765 - P 67,7 (vse)
A 118953 - G 78540 - B 40413 - P 66,0 (>=5)
A    475 - G   175 - B   300 - P 36,8 (>=1)
A   6602 - G  6550 - B    52 - P 99,2 (==0)

ls=0,625
A 126030 - G 85292 - B 40738 - P 67,7 (vse)
A 118863 - G 78536 - B 40327 - P 66,1 (>=5)
A    564 - G   206 - B   358 - P 36,5 (>=1)
A   6603 - G  6550 - B    53 - P 99,2 (==0)

ls=0,6875
A 126030 - G 85304 - B 40726 - P 67,7 (vse)
A 118807 - G 78520 - B 40287 - P 66,1 (>=5)
A    620 - G   234 - B   386 - P 37,7 (>=1)
A   6603 - G  6550 - B    53 - P 99,2 (==0)

ls=0,71875
A 126030 - G 85339 - B 40691 - P 67,7 (vse)
A 118755 - G 78537 - B 40218 - P 66,1 (>=5)
A    672 - G   252 - B   420 - P 37,5 (>=1)
A   6603 - G  6550 - B    53 - P 99,2 (==0)

ls=0,734375
A 126030 - G 85355 - B 40675 - P 67,7 (vse) <== NEJLEPŠÍ!
A 118699 - G 78542 - B 40157 - P 66,2 (>=5)
A    728 - G   263 - B   465 - P 36,1 (>=1)
A   6603 - G  6550 - B    53 - P 99,2 (==0)

ls=0,7421875
A 126030 - G 85205 - B 40825 - P 67,6 (vse)
A 118675 - G 78383 - B 40292 - P 66,0 (>=5)
A    752 - G   272 - B   480 - P 36,2 (>=1)
A   6603 - G  6550 - B    53 - P 99,2 (==0)

ls=0,75
A 126030 - G 85222 - B 40808 - P 67,6 (vse)
A 118666 - G 78399 - B 40267 - P 66,1 (>=5)
A    759 - G   273 - B   486 - P 36,0 (>=1)
A   6605 - G  6550 - B    55 - P 99,2 (==0)

ls=1
A 126030 - G 54684 - B 71346 - P 43,4 (vse)
A  40496 - G 22634 - B 17862 - P 55,9 (>=5)
A  29997 - G 15635 - B 14362 - P 52,1 (>=1)
A  55537 - G 16415 - B 39122 - P 29,6 (==0)

První přiblížení k použití valence a současně k použití
trigramů. Pravděpodobnost závislosti nově parametrizována otázkou, zda
už ekvivalentní závislý uzel pod tímtéž řídícím uzlem
visí. Ekvivalentní je takový uzel, který má stejnou morfologickou
značku (resp. ty dva znaky, které nám z ní zbyly).

G 84960 - B 41070 - P 67,4

Zhoršení. Zkusíme zjemnit definici ekvivalentních sourozenců. Pokud
mají oba pád, musejí ho mít stejný; jinak musejí mít stejné první
písmeno značky.



12.2.2002 večer doma

Opakování posledního testu, ale na domácích trénovacích a testovacích datech.

G 623 - B 301 - P 67,4

Pokus: z testovacích dat vynechány věty, které obsahují alespoň jednu závislost
typu ExD. Pokus je inspirován Carrollem et al. (1998), který do testování
experimentu se subkategorizačními pravděpodobnostmi při parsingu zahrnul pouze
věty pokryté svou gramatikou (tj. věty, ke kterým gramatika najde alespoň jednu
analýzu) s odůvodněním, že zbytek stejně obsahuje eliptické jmenné věty,
fragmenty dialogů a podobné podivnosti, které se stejně nesnaží pokrýt.

G 449 - B 215 - P 67,6

Dotažení pokusu do konce: dotyčné věty byly vynechány i při tréninku. Místo asi
1900 vět se trénovací množina scvrkla jen na 1246 vět.

G 446 - B 218 - P 67,2

Od diskriminace vět s ExD tedy zase ustupuji. Ustupuji také od parametrizace
pravděpodobností podle dvojčat, protože to úspěšnost nezvedlo a chyby, kterými
to bylo motivováno, se vyskytují vesele dál. Máme tedy opět 1983 trénovacích
vět a 924 testovacích závislostí.

G 608 - B 316 - P 65,8

Pozor! Takže úspěšnost na domácích datech je výrazně horší! V tomto světle
přestává být úplně jisté, že od věcí, od kterých jsem právě ustoupil, jsem
opravdu ustupovat měl. I když jistý není ani opak, statistická průkaznost
domácích dat je přece jenom nízká.

Opraveno počítání úspěšnosti pro závislosti vybrané náhodou (ve statistice měly
četnost 0). Chyba spočívala v tom, že se mezi tyto hrany připletly závislosti
koncové interpunkce na kořeni, které se přiřazují bez statistiky, tj. četnost u
nich nebyla uvedena, ale měly skoro stoprocentní úspěšnost.

A 924 - G 608 - B 316 - P 65,8 (vše)
A 749 - G 529 - B 220 - P 70,6 (>=5)
A 157 - G  71 - B  86 - P 45,2 (>=1)
A  18 - G   8 - B  10 - P 44,4 (==0)

Pokus: Vynechat z tréninku a testu věty, které obsahují koordinaci nebo
apozici. Z 1983 trénovacích vět zbylo 900. Z testovacích vět zbylo 21 (tj. 257
slov).

A 257 - G 187 - B 70 - P 72,8 (vše)
A 140 - G 119 - B 21 - P 85,0 (>=5)
A 111 - G  65 - B 46 - P 58,6 (>=1)
A   6 - G   3 - B  3 - P 50,0 (==0)



13.2.2002

Zopakován experiment s vynecháním koordinací a apozic. V trénovacích
datech zbylo 36200 vět, v testovacích 3496 vět.

A 41598 - G 31367 - B 10231 - P 75,4 (vše)
A 40805 - G 31050 - B  9755 - P 76,1 (>=5)
A   756 - G   303 - B   453 - P 40,1 (>=1)
A    37 - G    14 - B    23 - P 37,8 (==0)

Zopakován experiment s vynecháním ExD (koordinace a apozice
vráceny). V trénovacích datech zbylo 53500 vět, v testovacích 5522
vět.

A 99092 - G 68494 - B 30598 - P 69,1 (vše)
A 98253 - G 68200 - B 30053 - P 69,4 (>=5)
A   762 - G   283 - B   479 - P 37,1 (>=1)
A    77 - G    11 - B    66 - P 14,3 (==0)

Spojeny poslední dva pokusy. Vynechány jsou věty obsahující ExD,
koordinaci nebo apozici. V trénovacích datech zbylo 25900 vět,
v testovacích 2658.

A 36114 - G 27430 - B 8684 - P 76,0 (vše)
A 35300 - G 27076 - B 8224 - P 76,7 (>=5)
A   746 - G   340 - B  406 - P 45,6 (>=1)
A    68 - G    14 - B   54 - P 20,6 (==0)

Průzkum je hotov. Zkusím nicméně tento stav věcí nějakou dobu
ponechat. Jednak se tím zrychluje výpočet a jednak se můžu lépe
soustředit na druhy chyb, které s koordinacemi nesouvisejí.

Pokus: přestaneme do délky závislosti zahrnovat počet čárek, protože
tím se možná statistika příliš drobí. Ponecháme však informaci, zda se
na trase aspoň jedna čárka vyskytla, či nikoliv.

G 27435 - B 8679 - P 76,0

Zlepšení je minimální, ale alespoň se to nezhoršilo, takže to tak
necháme.

Valence - úvodní průzkum. Do výsledků jsou nyní zahrnuty pouze
závislosti typu Sb, Obj, Adv, Pnom. Typ se určí podle vzorové věty,
pokud byl závislý uzel zavěšen jinam, je to chyba. Analyzuje se ovšem
celá věta.

G 8848 - B 2569 - P 77,5

Tvary slovesa "být" zkopírovány do značek. Slibuji si od toho, že
konstrukce "bude dělat" ("dělat" má být řídící) se už nebude plést
s "může dělat" ("může" má být řídící).

G 9014 - B 2403 - P 79,0

Znova rozlišeny značky pro zvratná zájmena "se", "si" od ostatních
zájmen. Důvod: tato dvě zájmena hrají řádově větší roli při valenci
než všechna ostatní zájmena, takže by mělo pomoct, když si je nebudeme
plést. Poznámka: mezi funkcemi, které se mají kvůli valencím sledovat,
jsem zapomněl uvést AuxT. V nejbližším pokusu ho tedy ještě také
vynechám, pak se k němu vrátím.

G 9019 - B 2398 - P 79,0

Nepatrné zlepšení. A teď jak to vyjde při přidání kontroly AuxT?
(První výsledky jsou opakováním baseline, druhé opakováním pokusu s
přidaným "být", třetí opakováním pokusu s přidaným "se/si".)

G 9254 - B 2677 - P 77,6
G 9445 - B 2486 - P 79,2
G 9456 - B 2475 - P 79,3

Ještě vylepšení "být". Je-li záporné, odstranit předponu "ne-". Je-li
v příčestí minulém, odstranit koncovku rodu a čísla. U infinitivu se
zastaralou koncovkou "-ti" odstranit koncové "-i".

G 9489 - B 2442 - P 79,5

Nejprimitivnější valence. Zkusit přidat heslo každého slovesa do
značky (při zachování prvních dvou písmen značky). Pravděpodobně to
spíš uškodí, protože data příliš zřídnou bez náležitého vyhlazení, ale
za zkoušku to stojí.

G 6522 - B 5409 - P 54,7

Tak snad ani za zkoušku to nestálo. Ještě malý diletantský pokus
(diletantský, protože se příliš nezatěžuje dodržením zákonů
pravděpodobnosti): u závislostí, jejichž řídícím uzlem je sloveso,
udělat dva záznamy do téže tabulky: jeden bude mít v řídícím uzlu jen
morfologickou značku, druhý ji bude mít obohacenu o heslo jako v
předchozím pokusu. V závislém uzlu bude za všech okolností značka. Při
analýze se pak vytáhnou oba záznamy a četnosti se sečtou. Tím se
jednak trochu vyhladí řídkost dat, jednak se celkově zvýhodní
závislosti řízené slovesem oproti jiným, tj. slovesné vazby se snad
budou řešit o něco přednostněji.

G 9537 - B 2394 - P 79,9

Jednoduchá valence. Na začátku každé analýzy si najít všechna slovesa
ve větě, ke každému z nich všechny známé rámce, ty rozsekat na členy,
najít potenciální instance členů ve větě a všechny takto vzniklé
závislosti si zapamatovat jako valenční. Zatím se neptáme ani po tom,
zda je některá vazba povinná (vyskytuje se ve všech rámcích), ani zda
dvě různé valenční závislosti na tomtéž slovese jsou ze stejného rámce
tohoto slovesa, ani zda jedna valence není uspokojována opakovaně, ani
zda valenční závislost přeskakuje jiné sloveso, které má stejnou
neuspokojenou valenci. Na začátku každého kola pak hledáme nejdříve
valenční závislosti a teprve v případě, že žádná z nich není povolená,
hledáme mezi ostatními.

G 8660 - B 3271 - P 72,6

Zdá se, že tam, kde jedno sloveso má více variant rámců, zbytečně
vyhrávají ty méně pravděpodobné. Utřiďme tedy valenční závislosti
sestupně podle pravděpodobnosti.

G 8835 - B 3096 - P 74,1

A dále: valenční závislosti dostanou přednost pouze v případě, že už
je povolena ta nejlepší z nich. Jinak se postupuje normálním
způsobem. I tak samozřejmě může vyhrát valenční závislost, která není
nejlepší z valenčních.

G 9416 - B 2515 - P 78,9

Opravena chyba: nezvratná zájmena s pádem nebyla započítána jako
jmenné argumenty (jde zejména o vztažná a ukazovací zájmena - "to",
"který" apod.).

G 9426 - B 2505 - P 79,0

Zkusíme ještě jako druhé kritérium řazení valenčních závislostí přidat
délku závislosti (čím kratší, tím lepší).

G 9407 - B 2524 - P 78,8

Nezlepšuje se to. Než vrátíme náhodnou, zkusíme tedy, zda pomůže
přístup "čím delší, tím lepší".

G 9445 - B 2486 - P 79,2

Kupodivu je tu mírné zlepšení! Takže to tak necháme.

Zásobník valenčních závislostí se může zaseknout, pokud na jeho čele
vězí závislost, která už nikdy nebude povolena. V takovém případě je
nutné závislost ze zásobníku odstranit. Takový případ se pozná podle
toho, že nastala jedna z následujících podmínek: 1) závislý uzel už je
připojen jinde; 2) nad závislým uzlem vede závislost, která nevede nad
řídícím nebo obráceně.

G 9401 - B 2530 - P 78,8

Nepomohlo to a je to dost divoké, tak to vrátím do původního
stavu. Někdy bych mohl laděním vyzkoumat, co se tam vlastně děje a ve
kterých případech k tomu došlo, ale teď na to není čas.

G 9445 - B 2486 - P 79,2

Zkusím z testu vynechat Adv (většinou nejsou součástí valence).

G 5903 - B 1668 - P 78,0

Vrátíme Adv, vynecháme Sb (nejsou podchyceny valenčními rámci).

G 6962 - B 1953 - P 78,1

Vrátíme obojí.

G 9445 - B 2486 - P 79,2

Vynecháme z valence sloveso "být", protože samo už je bez valence
podchyceno celkem dobře a naopak se mnohokrát vyskytuje jako pomocné,
nebo s mnoha různými rámci, takže valence by ho mohla spíš poplést.

G 9455 - B 2476 - P 79,2

Zvýhodníme zavěšování těch vedlejších vět, které jdou snadno poznat,
ale dosavadní model na to nemá nástroj. Jakmile pod sloveso připojíme
zleva heslo "který", koukneme se, zda je před ním čárka, připojíme ji
také a potom hledáme nejbližší předcházející podstatné jméno nebo
zájmeno (mělo by se shodovat v rodě a čísle, ale to současné značky
neumožňují, tak to odložíme - stejně nepůjde o předmět ani podobnou
závislost, takže jde spíše o uklizení vedlejší věty než o její správné
zavěšení).

G 9507 - B 2424 - P 79,7

Zkombinovat "diletantskou pseudovalenci", kterou jsme nahoře dosáhli
79,9 %, s tím, co jsme použili v posledním pokusu. Důvod: teď sice
lépe než u pseudovalence preferuju valenční závislosti před
nevalenčními, ale pro rozlišení valenčních mezi sebou zase potřebuju
určitý stupeň lexikalizace, a ten byl v pseudovalenci obsažen.

G 9564 - B 2367 - P 80,2

Zvratná zájmena "se" a "si" jsou u některých sloves také zahrnuta pod
valencemi N4, resp. N3. Povolíme tedy obojí.

G 9560 - B 2371 - P 80,1

Malé zhoršení. Nové valence na sebe spíše nabalily různé další
kraviny. Výše uvedené druhy "se" a "si" je nutné nějak řešit, ale
takhle to nejde, takže beru zpět.

MUSIM ALE ZKONTROLOVAT seznam vazeb, který používám! Posledně
prováděný pokus jsem dělal, protože v seznamu vůbec nebylo "obrátit
se" (bylo tam pouze "obrátit N4"), přitom na webu je jasně vidět, že
existuje rámec "obrátit se na".



14.2.2002

Pokus: spojky "že", "aby" a ("zda" nebo "zdali") se přilepí ke
značce.

G 9635 - B 2296 - P 80,8

Ale zapomněl jsem upravit značky ve valencích, možná to bude ještě
lepší.

G 9619 - B 2312 - P 80,6

Ou nou! Jaktože je to zase horší? Musím to ale asi nechat takhle, je
to správnější.



21.2.2002

Pokus o pořádné změření některých výsledků uváděných ve článku do
Taibei. Musím se dokázat vrátit k původní verzi programu, v pátek před
odesláním článku jsem to dělal narychlo zbrkle a nepovedlo se mi to.

První krok: nyní lze v konfiguraci nastavit, zda se mají testovat
pouze hrany, které mají ve vzorových datech určitou analytickou
funkci, nebo všechny hrany. První výsledek je pro hrany s afuny Sb,
Obj, Adv, Pnom a AuxT (tedy stejné jako ve všech pokusech posledních
dnů), druhý je pro všechny hrany (afun .*).

G  9491 - B 2440 - P 79,5
G 27318 - B 8796 - P 75,6

Druhý krok: specifikaci afunů, které se nesmí ve větě vyskytnout, aby
věta nebyla vynechána, už konfigurace umožňuje. Nyní se zkusíme vrátit
na neomezená data. První výsledek je se zakázanými afuny ExD, Coord a
Apos (tak to bylo posledních několik dnů), druhý je pro povolené
všechny afuny při testu (avšak natrénováno je pořád na omezených
datech), třetí používá neomezená data při testu i při tréninku. Ve
všech pokusech už je ponecháno testování libovolných afunů (ve větách,
které nebyly vynechány).

G 27318 - B  8796 - P 75,6
G 84026 - B 42004 - P 66,7
G 83540 - B 42490 - P 66,3

Nižší úspěšnost třetího pokusu vzhledem k druhému je
překvapující. Kromě toho jsme klesli i pod původní
úspěšnost. Očekáváno:

G 85355 - B 40675 - P 67,7

Při zbrklém pátečním pokusu o návrat byly ovšem vyřazeny veškeré
machinace s morfologickými značkami, takže mimo jiné zmizel také
rozdíl mezi uzly závisejícími na kořeni, když ve větě bylo sloveso, a
když tam nebylo. Nyní naopak veškeré machinace vracím a budu je pak
vyřazovat postupně, s větším rozmyslem. Nejdříve ale průběžné
přetrénování a přetestování:

G 87589 - B 38441 - P 69,5

Nyní odstraníme tzv. selektivní lexikalizaci značek, tj. veškeré
machinace se značkami včetně přidávání lemmatu do značky pro
interpunkci. Výjimkou je pouze úprava značek pro křestní jméno, kde se
ale nepřidává lemma, nýbrž celá lexikální kategorie; kromě toho to
nesouvisí s valencí. Interpunkce s valencí taky moc nesouvisí, takže
ji v příštím kroku ještě také vrátím. Teď ale průběžné výsledky:

G 84314 - B 41716 - P 66,9

Vrácena lexikalizace značek pro interpunkci a předložky. (Předložky
byly lexikalizovány už 10.2.2002, interpunkce ještě dříve.)

G 85997 - B 40033 - P 68,2

Úspěšnost je pořád vyšší než před pokusy s valencí. Mohlo by to být
tím, že teď v délce závislosti eviduji výskyt čárky, tenkrát jsem
evidoval i počet čárek. Ještě tedy zkusím vrátit počet čárek. Ještě
jsem také nalezl násilnou úpravu vedlejších vět začínajících zájmenem
"který", a vypnul jsem ji.

G 85350 - B 40680 - P 67,7

Konečně jsem se trefil více méně do předvalenčního výsledku (jsem
jenom o pět závislostí horší). Teď tedy opět přestanu evidovat počet
čárek mezi řídícím a závislým a místo něj budu evidovat pouze
existenci čárky.

G 85360 - B 40670 - P 67,7

Vypínám lexikalizaci předložek, ta se stane součástí balíku
"selektivní lexikalizace", a nemůže se tedy započítávat do baseline
před valenčními pokusy. Při selektivní lexikalizaci už navíc nebudu
pracovat s použitým tvarem předložky, ale s jejím lemmatem.

G 85139 - B 40891 - P 67,6

Příště je potřeba se nějak postavit k násilnému řešení vedlejších vět
začínajících zájmenem "který". Je třeba pokrýt i další vztažná
zájmena, kterých se to týká. Je třeba zjistit, jak moc pomáhá povinné
připojování takových vět k nejbližšímu předcházejícímu podstatnému
jménu a kolikrát přímo toto připojení bylo špatně či správně. Je třeba
se zamyslet, zda nebude lepší nějaký volnější a statističtější model,
který např. bude podmiňovat obyčejnou pravděpodobnost podmínkami,
které při násilném řešení vedou přímo k připojení vedlejší věty. A
celá tato funkce by asi měla být volitelná v konfiguraci. Pokud se
rozhodnu mít ji pro valenční pokusy zapnutou, měla by být součástí
baseline.



22.2.2002

Pokus s povinným připojováním vztažných vedlejších vět k nejbližší
jmenné frázi nalevo od čárky. Zatím vrátím to, co už tam jednou bylo,
tedy věty se zájmenem "který" v různých rodech. Udělám to jako
volitelnou funkci, ale pro nejbližší pokus bude zapnuta. Zvlášť také
změřím úspěšnost těchto závislostí, protože jedna věc je, kolikrát
byly úspěšné ony samy, a jiná, kolik chyb odstranily nebo naopak
způsobily jinde ve stromě.

Vztažné věty budeme testovat na malém vzorku 445 vět (soubory
lu0?.a). Tady je jeho počáteční úspěšnost:

G 5424 - B 2477 - P 68,6

První řádek je vždy celková úspěšnost, druhý jen vztažné věty.

G 5487 - B 2414 - P 69,4
G   30 - B   16 - P 65,2

To je pozoruhodné! Jak je vidět, samotné zavěšení vztažných vět je
natolik chybné, že celkovou úspěšnost kazí, avšak i tak pomáhá
umravnit jiné závislosti, díky čemuž celková úspěšnost naopak
vzrostla! Možná ale, že zavěšení vztažných vět bylo chybné i předtím,
akorát chyby směřovaly jinam, takže celkově i tohle je zlepšení (nemám
totiž možnost jednoduše změřit úspěšnost zavěšení vztažných vět, když
není použito zvláštní zacházení). To skoro stojí za zmínku v nějaké
publikaci. A teď musíme zjistit, kde k chybám dochází a zda se s nimi
dá něco dělat.

Chyby lze rozdělit do následujících skupin:
1) Jmenná fráze nebo sloveso ve vedlejší větě jsou členy nějaké
koordinace nebo apozice. To zatím neumím opravit, protože zatím neumím
zacházet s koordinacemi a apozicemi.
2) Správná jmenná fráze rozvita zprava jinými jmennými frázemi v
genitivu nebo předložkovými frázemi. Zatím obecně neumím opravit a
řešení bude velmi obtížné, řízené leckdy sémanticky nebo dokonce ani
člověkem nerozhodnutelné. Možná by nicméně stálo za průzkum, zda není
naopak častější zavěšení na nejvyššího člena takového řetízku, místo
na nejnižšího, který je současně nejblíže k vedlejší větě.
3) Jako předchozí skupina, avšak špatná jmenná fráze se se vztažným
zájmenem neshoduje v rodě a čísle. To umím opravit.

Zakázáno věšení, kde není shoda (nevěším pak ale nikam, ani na
nejbližší shodnou jmennou frázi, je to zas necháno na statistice).

G 5477 - B 2424 - P 69,3
G   29 - B    7 - P 80,6

Celkové úspěšnosti to sice nepomohlo, ale nemůžu dělat vědomě chyby,
abych zabránil jiným, musím raději hledat jiný způsob odstranění těch
jiných. Nyní zkusím navíc najít shodnou jmennou frázi, na kterou by
vedlejší věta šla zavěsit.

G 5486 - B 2415 - P 69,4
G   33 - B   11 - P 75,0

Místo zájmena "který" nyní vyzkoušíme zájmeno "jaký".

G 5422 - B 2479 - P 68,6
Vztažná věta uvedená zájmenem "jaký" se neobjevila ani jednou!

Vracíme zájmeno "který", zájmeno "jaký" vypouštíme. Vracíme se k
velkým testovacím datům.

G 85830 - B 40200 - P 68,1
G   390 - B   128 - P 75,3

Rozšíříme pravidlo na výskyty zájmena "který" v předložkových frázích
(např. "Muž, na kterého byla podána žaloba..."). Budeme také počítat,
kolikrát se zájmeno "který" vyskytlo v testovacích datech celkem, aby
se poznalo, jak velkou část problému jsme vůbec schopni uchopit.

G 85844 - B 40186 - P 68,1
G   400 - B   133 - P 75,0
výskyty zájmena "který" = 124064

Tak to je tedy k smíchu, vždyť 533 zachycených výskytů "který" tvoří z
celkového počtu pouhá 4 promile! To se divím, že zásah měl vůbec
alespoň takový vliv, jaký měl. Na vině je samozřejmě přísný výběr
okolností, a některým okolnostem by se snad dalo pomoci bez nebezpečí
ztrát - například se požaduje, abych v daném okamžiku měl už zájmeno i
čárku připojené. Nemám-li, třeba to prošvihnu. Nebudu ale teď už tento
směr sledovat dál, protože v něm stejně není žádná statistika. Raději
se vrátím ke sledování valence a sběru podkladů pro konečnou verzi
článku do Taibei.

Vyhodnocení baseline (úplně nelexikalizovaného parseru) paralelně pro
všechny závislosti a pro valenčně důležité závislosti.

G 85889 - B 40141 - P 68,1 (vše)
G 25459 - B  7936 - P 76,2 (valence)

Lexikalizace s ls=0,734375

G 85844 - B 40186 - P 68,1 (vše)
G 25446 - B  7949 - P 76,2 (valence)

Tak teď už tohle ani není optimální ls, protože když jsem ho
stanovoval, byl celý model trošičku odlišný. Naštěstí rozdíly jsou tak
nepatrné, že na desetinách procenta se zhoršení neprojeví a bude to
vypadat, že se nic nehnulo ani nahoru, ani dolů.

Úplná obyčejná lexikalizace, tj. ls=1, následuje:

G 54844 - B 71186 - P 43,5 (vše)
G 14426 - B 18969 - P 43,2 (valence)

Obyčejná lexikalizace vrácena na 0,734375, přidána selektivní
lexikalizace (sloveso "být", předložky, podřadící spojky a zvratná
zájmena).

G 87615 - B 38415 - P 69,5 (vše)
G 25098 - B  8297 - P 75,2 (valence)

Přidána "pseudovalence" (závislostem obsahujícím slovesa se sčítá
jejich pravděpodobnost podle značek s pravděpodobností, kde značka
slovesa je lexikalizovaná heslem).

G 87735 - B 38295 - P 69,6 (vše)
G 25299 - B  8096 - P 75,8 (valence)

A nakonec přidána opravdová valence v rozsahu, ke kterému jsem se při
přípravě článku zatím dostal (preference valenčních závislostí). Vše
výše uvedené zůstává také zapnuto.

G 87645 - B 38385 - P 69,5 (vše)
G 25259 - B  8136 - P 75,6 (valence)

A teď budeme postupovat zase zpátky, ale všechno budeme měřit při
vynechaných větách obsahujících ExD, Coord nebo Apos.

G 28592 - B 7522 - P 79,2 (vše)
G  9629 - B 2302 - P 80,7 (valence)

Nyní vypnu valenci.

G 28644 - B 7470 - P 79,3 (vše)
G  9652 - B 2279 - P 80,9 (valence)

Nyní vypnu i pseudovalenci.

G 28643 - B 7471 - P 79,3 (vše)
G  9608 - B 2323 - P 80,5 (valence)

Nyní vypnu i selektivní lexikalizaci.

G 27556 - B 8558 - P 76,3 (vše)
G  9544 - B 2387 - P 80,0 (valence)

Nyní změním ls na 1 (úplná obyčejná lexikalizace).

G 17557 - B 18557 - P 48,6 (vše)
G  4984 - B  6947 - P 41,8 (valence)

Nyní změním ls na 0 (žádná lexikalizace).

G 27496 - B 8618 - P 76,1 (vše)
G  9520 - B 2411 - P 79,8 (valence)

Pokus: do selektivní lexikalizace přidat příslovce neodvozená z
přídavných jmen (uzavřená skupina, značka Db).

G 28554 - B 7560 - P 79,1 (vše)
G  9561 - B 2370 - P 80,1 (valence)

Proti dosud nejlepším výsledkům s valencí je to drobné
zhoršení. Přidáme k nim ještě příslovce se značkou Dg, ale heslem
"hodně" nebo "málo-3" (jde nám hlavně o druhé stupně "více než" a
"méně než").

G 28558 - B 7556 - P 79,1 (vše)
G  9570 - B 2361 - P 80,2 (valence)

Příslovce typu Db ruším, příslovce "hodně" a "málo" ponechávám a do
značky nedávám jejich heslo, ale slovo.

G 28587 - B 7527 - P 79,2 (vše)
G  9632 - B 2299 - P 80,7 (valence)

Ruším i příslovce "hodně" a "málo".

G 28592 - B 7522 - P 79,2 (vše)
G  9629 - B 2302 - P 80,7 (valence)



26.2.2002

Zakázáno, aby více než jedna závislost vedla dovnitř úseku
ohraničeného čárkami.

G 28703 - B 7411 - P 79,5 (vše)
G  9930 - B 2001 - P 83,2 (valence)

Opraveno: koncová interpunkce je nyní samostatným úsekem. Totéž platí
o kořeni.

G 29149 - B 6965 - P 80,7 (vše)
G 10009 - B 1922 - P 83,9 (valence)

To je hezké, teď ale hořím zvědavostí, jak to bude vypadat, když
nebudu vynechávat koordinace a spol.!

G 91142 - B 34888 - P 72,3 (vše)
G 27256 - B  6139 - P 81,6 (valence)

Teď se zase jednou podíváme, jak by nám pomohl Melk. Má to ale
háček. Musíme použít nezávislé testování a to nám nebude dělat
transformace koordinací. Jinými slovy, na koordinacích hodně ztratíme,
protože dokonce ani nebudeme zkoušet přeskládat je ve stromě, který
jsme vymysleli. Nezávislý test bez melku tedy dopadá takto:

G 83159 - B 42871 - P 66,0

Pád je možná ještě výraznější, než by se čekalo, a to proto, že ve
větách s koordinací neplatí pravidlo o uzavřenosti mezičárkových
úseků! Např. ve větě "Viděl Martina, Lucku a Janu." se musí nejdříve
přes čárku spojit Martin s Luckou a Janou, teprve potom se to celé
spojí s "viděl" a "viděl" - opět přes čárku, byť pomyslnou a na druhou
stranu - se spojí s kořenem.

Při postsubstituci melku (v nějakém stavu z loňského léta, tj. bez
vylepšení, která jsem k němu ještě vymýšlel na podzim):

G 83577 - B 42453 - P 66,3

Jasný úkol nejbližších dní tedy je: VYŘEŠIT KOORDINACE A APOZICE!!!
Vězí v nich příliš mnoho, určitě alespoň 10% úspěšnosti.



27.2.2002

Zahajuji frontální útok na koordinace. Nebudou se konat žádné podvodné
transformace vzorových analýz při testování, místo toho se rovnou
vybuduje správná (tj. definicí PDT požadovaná) struktura koordinace.

Krok 1: Vypnout při tréninku i testu transformace koordinací. Nutně
musí nastat další pád úspěšnosti.

G 86994 - B 39036 - P 69,0

Kupodivu se úspěšnost naopak trochu vrátila nahoru. Snad tedy přece
jenom měl dostatečnou sílu fakt, že trénujeme a testujeme stejným
způsobem. V kroku 2 ovšem tento fakt opět trochu narušíme.

Krok 2: Při tréninku vynechat závislosti, jejichž řídícím nebo
závislým uzlem je koordinační spojka. Test zatím ponechat beze změny,
adekvátní úprava testu bude provedena v některém z pozdějších kroků.

G 84078 - B 41952 - P 66,7

Teď se pochopitelně projevila naprostá neznalost koordinací při
testu. Nevadí, ty se totiž budeme učit zvlášť.

Krok 3: Při testu se v každém kole dívám, zda jsou mezi povolenými
závislostmi obě půlky dvoučlenné koordinace: závislost čehokoli na
souřadící spojce a závislost druhého člena stejného druhu (co do
morfologické značky) na té samé spojce z druhé strany. Pokud je taková
dvojice závislostí povolená, dostane přednost. To je sice dost hrubý
zásah do statistického přediva, ale posléze bude metoda hrubé síly i
zde nahrazena modelem.

G 87276 - B 38754 - P 69,3

Krok 3b: Oprava. Jednou použitá koordinační spojka je zablokovaná pro
další potenciální koordinace. K zablokování se navíc použije přepsání
její značky značkou posledního koordinovaného členu, takže se také
usnadní zavěšování koordinace nahoru nebo nabalování slov
rozvíjejících celou koordinaci.

G 87928 - B 38102 - P 69,8

Krok 3c: Drobné vylepšení. Slovesa mají jen dvě třídy: Vf (infinitiv) a
V (všechno ostatní, tj. určité tvary slovesa). Předpokládám, že
později bude tento zásah nahrazen jemnější statistikou o tom, jaké
kategorie se jak často spojují do koordinací, ale zatím, v prostředí
hrubé síly, je lepší tohle než nic.

G 88265 - B 37765 - P 70,0

Krok 4: Rozšířit na vícečetné koordinace! Pokud je povolena závislost
čárky na bývalé koordinační spojce (bývalé proto, že už byla zapojena
do koordinace a nyní je přepsána jedním ze členů) a pokud nejbližší
nezavěšené slovo nalevo od této čárky je stejného druhu jako členové
koordinace, připojit čárku pod koordinační spojku a nařídit připojení
onoho slova tamtéž v příštím kole.

G 88561 - B 37469 - P 70,3

Krok 4b: Opravit slovesné třídy i u vícečetných koordinací.

G 88594 - B 37436 - P 70,3

Krok 5: První pokus o přidání statistik. Koordinace se souřadícími
spojkami (J^) se dělají nadále natvrdo, přibyla však možnost
dvoučlenných koordinací s jinými spojkami (čárky, jiné slovní
druhy...). Pokud kolem takové spojky existují dva volné uzly,
pravděpodobností koordinace je relativní četnost jejich výskytu jako
členů v téže koordinaci. Tato pravděpodobnost soutěží s
pravděpodobnostmi obyčejných závislostí. Pokud vyhraje, má druhý člen
koordinace přidání do stromu jisté.

G 86448 - B 39582 - P 68,6

Krok 5b: Oprava. Tak jako v 3b i tady zablokováno, aby po použití
spojky v koordinaci byla ta samá spojka použita pro jinou koordinaci
vzdálenějších členů. Tentokrát už neblokujeme změnou morfologické
značky - bylo by to neúčinné, protože spojka se nepoznává podle
značky, ale podle hesla. Místo toho vyplníme jedničku do prvku pole
$coord s indexem odpovídajícím indexu spojky ve větě.

G 87846 - B 38184 - P 69,7

Krok 5c: Na statistiku najíždí i souřadící spojky (J^).

G 83291 - B 42739 - P 66,1

Krok 5d: Oprava. Pole $coord se nyní po analýze každé věty vymazává.

G 85295 - B 40735 - P 67,7

Krok 5e: Oprava. Řada koordinací se zablokovala předčasně, jen proto,
že už se o nich někdy uvažovalo.

G 85247 - B 40783 - P 67,6

Krok 5f: Oprava. Není sice vůbec jisté, že relativní četnosti
koordinačních ekvivalencí jsou porovnatelné s relativními četnostmi
závislostí, ale pokud by tomu tak mělo být, museli bychom relativní
četnosti koordinací zmenšit (1-$ls)-krát, protože jsou postaveny na
značkách a pravděpodobnosti závislostí se skládají z modelů značek a
slov. Proto nyní násobím koordinační relativní četnosti uvedeným
faktorem.

G 86235 - B 39795 - P 68,4

Krok 5g: Oprava. Tak jako ve 3b, opět se kopíruje značka jednoho ze
členů koordinace do značky koordinační spojky. Tentokrát ovšem
výsledek může být horší, protože někdy se zkoordinují věci rozdílných
typů a pak se může stát, že bude vybrán ten méně reprezentativní typ.

G 86812 - B 39218 - P 68,9

Krok 5h: Lepší pravděpodobnostní model (přetrénováno). Nyní už se
nesleduje, jak často daná spojka řídila právě koordinaci daného druhu,
protože jsem to stejně nevyužíval. Zato se zjišťuje, jak často dané
heslo bylo koordinační spojkou vzhledem ke všem svým výskytům, a tímto
číslem se násobí celková pravděpodobnost koordinace. Takže koordinaci
už nemagnetizuje kdejaký hejhula v čele s čárkami - šance vyhrát
reálně už zůstává opět především souřadícím spojkám.

G 87268 - B 38762 - P 69,2



28.2.2002

Krok 5i: Oprava. Při trénování nesledovat heslo, ale slovní tvar
spojky. Heslo v tomto případě paradoxně poskytuje častěji více
možností, a to proto, že mnohé spojky patří k heslům s rozlišenými
významy (plus-1, plus-2) a lematizátor je ne vždy trefí.

G 87242 - B 38788 - P 69,2

Došlo dokonce k nepatrnému zhoršení, i když procentuální úspěšnost se
fakticky nezměnila. Pro příště by ale mělo být bezpečnější použití
slov místo hesel, takže to tak nechám.

Krok 6: Teď je potřeba přidat vícečetné koordinace. Při tréninku nově
sledujeme, které spojky jsou schopny řídit i vícečetné koordinace
(nejsou to všechny, například u pomlčky nebo dvojtečky to
neočekávám).

G 87385 - B 38645 - P 69,3

Krok 6b: Oprava. Do kořene koordinace se nesmí kopírovat typ
koordinace, pokud už tam je (tj. pokud rozšiřuju existující
koordinaci).

G 87450 - B 38580 - P 69,4

Krok 6c: Oprava. Při tréninku rozebrat složené koordinace, aby se
nestalo, že podstatné jméno bude koordinačně ekvivalentní se souřadící
spojkou. Ani teď to ale nedělám pořádně, protože pouze přeplácnu
koordinaci, která už byla zpracována, ale nemám jistotu, že ještě před
jejím zpracováním nenarazím na koordinaci, do které je vložena, nebo
na závislost, která na ní visí nebo kterou ona sama visí na někom.

G 87164 - B 38866 - P 69,2

Krok 7: Je potřeba přijít na to, kdy se má dávat přednost koordinacím
a kdy ne. Radikální krok: k nenulovým pravděpodobnostem koordinací,
přičíst 1. Tím se zajistí, že pokud by to mohla být koordinace, pak
dostane přednost.

G 74126 - B 51904 - P 58,8

To ale dostávají přednost i koordinace se spojkami, které v 99 % svých
výskytů nemají s koordinacemi nic společného, a koordinace členů,
které se na jedné koordinaci podílely jen omylem. Mohli bychom tedy
zkusit jiný podvod. Koordinace dostane přednost, pokud je alespoň 50 %
pravděpodobnost, že je to opravdu koordinace, neboli že domnělá spojka
je opravdu koordinační spojkou a že domnělé členy opravdu mohou být
pohromadě v jedné koordinaci. Pro první pravděpodobnost už máme
statistiku. Pro druhou bychom počet výskytů značky v koordinaci s
konkrétní jinou značkou potřebovali dělit celkovým počtem výskytů
první značky v koordinacích, a ten zatím neznáme. Zatím tedy budeme
požadovat, aby obě značky byly shodné.
(Krok 7b.)

G 87772 - B 38258 - P 69,6

Krok 7c: Oprava. Pokud dvojice značek nebyla při tréninku vidět v
žádné koordinaci, ale značky jsou totožné, pravděpodobnost jejich
koordinační ekvivalence direktivně nastavit na 1.

G 87844 - B 38186 - P 69,7

Krok 7d: Koordinace s mnoha čárkami a žádnou jasnou spojkou se spojují
hierarchicky, a to proto, že nejdříve se spojí první dva členy pod
čárkou mezi nimi a pak už není úniku. Odteď mezi stejnými koordinacemi
preferovat ty, jejichž spojka leží více vpravo.

G 87847 - B 38183 - P 69,7

Špatná zpráva od Petra Pajase: "atd" a podobné zkratky jsou zavěšovány
pokaždé jinak, achich achich! Pokud lze zavěsit na něco jiného
(např. čárku), udělá se to a "atd" je potom (obvykle) jedním ze členů
koordinace. Samotné "atd" řídí koordinaci pouze pokud jiný kandidát
není, tedy např. ve větě "Přišel Tonda atd." V manuálu k analytické
rovině je to napsáno trochu jinak, ale prý špatně. V datech to také
není vždy správně, např. věta na začátku testovacích dat s obří
koordinací má v kořeni koordinace atd., přestože před ním jsou spousty
čárek.

Krok 7e: Zrušeno zkreslování pravděpodobností koordinací na základě
jejich pořadí ve větě - i tak je tam toho zkreslování dost. Je potřeba
odstranit i absolutní preferenci koordinací jako takových, ale kde
najít vhodné vyvážení se závislostmi? Někdy je potřeba nejdříve
připojit přídavné jméno k podstatnému a pak teprve spojit podstatná
jména do koordinace, jindy je nutné nejdříve spojit koordinaci
přídavných jmen a pak teprve výsledek připojit závislostí k
podstatnému jménu.



1.3.2002

Pokus: pokud lze přídavné jméno buď zavěsit na podstatné jméno
doprava, nebo koordinovat s jiným přídavným jménem vlevo, dostane
přednost koordinace. V ostatních případech rozhoduje statistika. Pokud
pokus vyjde, pokusím se ho také podchytit statisticky.

G 87855 - B 38175 - P 69,7

Krok 8: První pokus s částečným podmíněním výběru zavěšení kontextem
ostatních možností výběru. Ve stejnou chvíli byla vypnuta valence (ne
pseudovalence ani selex), protože v současné podobě spíše mírně
škodí. Přesto úspěšnost zatím mírně klesla, ale jsem optimista, až to
dodělám, bude to snad lepší!

G 87454 - B 38576 - P 69,4

Krok 8b: K souboji s konkurenty vlevo přidán souboj s konkurenty
vpravo. Další zhoršení :-(

G 87172 - B 38858 - P 69,2
Doplňková statistika:
Levý konkurent 946 x pomohl, 985 x ublížil, zbytek špatný i bez něj.
Pravý konkurent 1080 x pomohl, 1454 x ublížil, zbytek špatný i bez něj.

Krok 8c: Zkusíme zvýšit přesnost na úkor úplnosti. Konkurentům
dovolíme zvítězit pouze s počtem výskytů 10 nebo větším.

G 87864 - B 38166 - P 69,7
lkl 806:761 lkp 784:648

Krok 8d: OK, navíc ještě budeme požadovat, aby převaha konkurenta nad
původním kandidátem byla alespoň dvoutřetinová.

G 88210 - B 37820 - P 70,0
lkl 634:381 lkp 606:479

No sláva, aspoň že tak! Uvidíme se příští týden...



4.3.2002

Krok 8e: Soutěží o vítěze lokálních konfliktů se zatím vůbec
neúčastnily koordinace (přestože potřebné statistiky byly při tréninku
získány). Nyní tedy přidávám i koordinace.

8e1: Řešení lokálních konfliktů muselo být kvůli koordinacím
přebudováno. V zájmu dobrého odladění tedy nejdříve zkusíme zopakovat
výsledky, kde se LK řeší pouze pro závislosti.

G 87546 - B 38484 - P 69,5
lkl 644:756 lkp 622:503

Zhoršení o 664 závislostí. Někde je chyba.
8e2: Pokusíme se tedy zopakovat výsledek bez řešení LK.

G 87920 - B 38110 - P 69,8

Výsledek je o 65 závislostí lepší než poslední výsledek před krokem 8,
ale to bude tím, že na začátku kroku 8 jsme také vypnuli valence, a ty
zůstaly vypnuté i teď.

Rozdíl mezi 8e1 a 8d může být ještě v pořadí testování
závislostí. Jakmile se najde první konkurenční závislost, která je
"dostatečně lepší" než původní kandidát, použije se tato závislost a
lepší už se nehledá. Pořadí procházení konkurentů tedy hraje
roli. Neumím sice asi dokonale zopakovat pořadí z kroku 8d, ale můžu
před procházením konkurentů uspořádat konkurenty podle vzdálenosti od
závislého uzlu.

G 87546 - B 38484 - P 69,5

8e3: Zjišťuju, že přece jenom nejsou vypnuty koordinace. Tak teď už je
vypínám doopravdy.

G 88209 - B 37821 - P 70,0

Tak jsme konečně skoro přesně (až na jednu závislost, důvod neznám)
tam, co v pátek večer. Špatná zpráva ovšem je, že přidáním koordinací
se model zjevně opět zhorší. (Výsledek viz 8e1.)

8f: Opravena chyba. Za koordinační spojku se počítalo kde co včetně
např. předložky "z". Nyní se síla koordinace jako konkurenta násobí
pravděpodobností, že použitá koordinační spojka je skutečně
koordinační spojka.

G 88000 - B 38030 - P 69,8
lkl 636:519 lkp 609:480

Tak teď už je to snad technicky bez chyb, ale ten model... Nechápu,
jak je například možné, že "A1 L C N1 P N1" (přídavné jméno mohlo být
spojeno doleva koordinací s podstatným jménem, nebo rozvíjet jiné
podstatné jméno napravo) vyhrála koordinace 30:0!

Tak je to proto, že tagger označil první přídavné jméno chybně jako
podstatné (např. ve větě "Dobré i špatné výsledky se vyskytují u všech
používaných systémů.") Pokud chceme při analýze používat výstup
taggeru, tak asi nemůžeme při tréninku jeho názory opravovat. Měli
bychom je však přebít. Neděje se tak možná proto, že zatím při sbírání
poražených konkurentů bereme v úvahu jen opravdové koordinace, ale při
analýze zkoumáme všechny potenciálně možné koordinace. Musíme tedy i
při tréninku zkoumat, zda by něco mohlo být koordinační spojkou, a
pokud ano, musíme odhadnout, kteří z jeho sousedů na druhé straně by
při analýze mohli figurovat jako koordinovaní sourozenci. Tohle je
obtížná část. Asi by se opět měla procházet všechna slova za spojkou,
která nejsou svázána s nějakým slovem na naší straně spojky.



6.3.2002

8g: Opraveno trénování tak, jak je uvedeno výše. Nastalo mírné
zlepšení.

G 88243 - B 37787 - P 70,0
lkl 661:409 lkp 608:482

8h: Ze skutečných koordinací při trénování vynechány složené (abych se
neučil koordinaci se spojkou), ale podle očekávání se na výsledku nic
nezměnilo.

G 88243 - B 37787 - P 70,0
lkl 661:409 lkp 608:482

8i: Při souboji s konkurenty nevyhraje první konkurent, který je
lepší, ale ten nejlepší z lepších konkurentů. Na výsledcích to skoro
nic nemění (zlepšení všeho všudy o dvě hrany). Při bližším pohledu na
statistiku lokálních konfliktů je však vidět větší pohyb: přibylo
šťastných, ale i nešťastných zásahů.

G 88245 - B 37785 - P 70,0
lkl 687:455 lkp 620:505

8j: Souboj s konkurenty nyní probíhá tak, že se projdou všechny
dvojice levý kandidát - pravý kandidát, které pro zavěšení daného uzlu
přicházejí v úvahu. Na rozdíl od dosavadních pokusů se tedy může stát,
že konkurs na řídící uzel vyhraje někdo na stejné straně jako původní
kandidát, ale nebude to původní kandidát.

G 76707 - B 49323 - P 60,9
LKG 4164 - LKB 13726

8j1: Vítěz musí mít alespoň 10 hlasů, jinak se použije kandidát podle
nekontextové pravděpodobnosti.

G 78190 - B 47840 - P 62,0
LKG 3019 - LKB 11544

8j2: Vítěz musí být alespoň dvakrát lepší než druhý nejlepší, jinak se
použije kandidát podle nekontextové pravděpodobnosti.

G 87296 - B 38734 - P 69,3
LKG 2185 - LKB 2809

8j3: Vítěz nesmí mít nekontextovou pravděpodobnost nulovou (což může
nastat i kvůli kontrole mezičárkových úseků).

G 87496 - B 38534 - P 69,4
LKG 1867 - LKB 2158

Pozastavuji vývoj tímto směrem a vracím se k první generaci lokálních
soubojů, kterou se pokusím rozvíjet jinak.

G 88245 - B 37785 - P 70,0
LKG 1307 - LKB 960

Krok 9: Připravuji možnost změnit pořadí, ve kterém se přidávají nové
hrany do stromu. Dosud se vždy bere hrana s nejvyšší nekontextovou
pravděpodobností a pouze lokální souboje na tom můžou něco změnit. V
první části kroku 9 ještě toto pravidlo zachovám, ale přepíšu parser
tak, aby nejdříve hledal závislý uzel a potom vybíral z kandidátů na
jeho řídící uzel. V dalších podkrocích pak bude snadné nahradit
pravidlo pro výběr závislého uzlu jiným.

9a: Vybírá se závislý uzel z nejlepší závislosti, ale ne z nejlepší
koordinace.

G 87033 - B 38997 - P 69,1
LKG 1334 - LKB 976

9b: Vybírá se závislý uzel z nejlepší závislosti nebo
koordinace. Výsledky by měly být rovny dosavadnímu maximu (70%).

G 88245 - B 37785 - P 70,0
LKG 1317 - LKB 962 (??? - odkud ten rozdíl?)

9c: Vybírá se závislý uzel, jehož řídící uzel vyhraje s největší
absolutní silou (tj. počet výher při tréninku, nikoli poměr počtu
výher k počtu proher).

G 75694 - B 50336 - P 60,1

9d: Vybírá se závislý uzel, jehož řídící uzel vyhraje lokální konkurz
s největší relativní silou (tj. poměr počtu výher a počtu proher).

G 76179 - B 49851 - P 60,4

9e: Vybírá se závislý uzel, který má nejvíce kandidátů na řídícího.

G 47869 - B 78161 - P 38,0

9f: Vybírá se závislý uzel, který má nejméně kandidátů na řídícího.

G 47869 - B 78161 - P 38,0 (??? proč je to stejné jako 9e?)

To je taky pěkná blbost. Na začátku se vybere poslední slovo věty,
protože má jen jednu možnost, to ovšem vůbec nemusí být ta pravá. A
pak se podobně vybírá momentálně poslední volné slovo až kdoví do
kdy.

9g: Ještě mám nápad, že by se mohly upřednostňovat závislé uzly, které
jsou obvykle blíže k listům stromu, protože je samozřejmě žádoucí,
abych zavěšoval uzel až ve chvíli, kdy je jeho podstrom (a také
podstromy jeho sourozenců) kompletně postavený. Teď už ale nemám chuť
to implementovat, takže pro dnešek se vracím k výběru závislého uzlu
podle toho, zda figuruje v hraně s největší četností.

G 88242 - B 37788 - P 70,0
LKG 1317 - LKB 963



24.5.2002

Zase na čas opouštím koordinace a vracím se k subkategorizaci (kvůli
dokončení článku na Coling 2002 do Taibei). Protože uplynulo 2,5
měsíce a spoustu jsem toho zapomněl, pro začátek jen nové
přetrénování, otestování a porovnání s výsledky zaznamenanými
výše. Žádné věty nejsou vyloučeny, ale v závorce je uvedena úspěšnost
pouze na Sb|Obj|AuxT|Pnom|Adv. Skutečná valence při tomto pokusu není
zapnuta (valenční závislosti nejsou upřednostňovány). Selektivní
lexikalizace zapnuta je.

G 88273 - B 37757 - P 70,0 (78,6)

Podobný pokus, ale trénovací a testovací data se omezují na věty bez
ExD, Coord a Apos.

G 28869 - B 7245 - P 79,9 (82,7)



15.6.2002

Ještě hlouběji do minulosti: je vypnuta i selektivní
lexikalizace. První řádek obsahuje věty bez ExD, Coord a Apos, druhý
řádek věty bez ExD, třetí řádek všechny věty.

G 28230 - B  7884 - P 77,5 (80,1)
G 66862 - B 32230 - P 67,5 (77,7)
G 83782 - B 42248 - P 66,5 (77,1)
--------------------------------- totéž pro lambda = 0
G 28145 - B  7969 - P 77,3 (79,9)
G 67800 - B 31292 - P 68,4 (77,7)
G 82382 - B 43648 - P 65,4 (77,0)
--------------------------------- totéž pro lambda = 1
G 23170 - B 12944 - P 46,7 (40,7)
G 44815 - B 54277 - P 45,2 (42,5)
G 57086 - B 68944 - P 45,3 (42,4)

Nadále bude napevno lambda = 0,734375. Opět pro všechny tři množiny
dat, tentokrát zapneme selektivní lexikalizaci.

G 28828 - B  7286 - P 79,8 (82,0) bez ExD, Coord a Apos
G 69394 - B 29698 - P 70,0 (79,2) bez ExD
G 85695 - B 40335 - P 68,0 (78,5) vše

Selektivní lexikalizace zůstane zapnuta, navíc zapneme pseudovalenci.

G 28801 - B  7313 - P 79,8 (82,1) bez ExD, Coord a Apos
G 69409 - B 29683 - P 70,0 (79,3) bez ExD
G 85730 - B 40300 - P 68,0 (78,7) vše



16.7.2002

Porovnání mého a Charniakova parseru (které chyby, které dělá on,
nedělám já a obráceně). Kvůli tomu je potřeba se vrátit k nastavení,
se kterým můj parser dosáhl nejvyšší úspěšnosti (70 %). Zapínám řešení
lokálních konfliktů.

17.7.2002

Porovnání i s Collinsovým parserem. Výsledky jsou následující (číslo
znamená počet závislostí, zkratky vedle uvádějí, které parsery měly
právě tyto závislosti určené dobře):

77995 ec+mc+dz
18508 ec+mc
 3951 ec+dz
 3801 mc+dz
 5765 ec
 3662 mc
 2525 dz
 9821 -



19.7.2002

Zpřísněná kontrola závislostí vedoucích přes čárku. Nyní nesmí žádná
závislost překročit čárku nejen když úsek, do nějž náleží závislý
uzel, není hotový, ale ani když kterýkoli jiný mezičárkový úsek ještě
není hotový. Jinými slovy: nejdřív pospojovat úseky mezi čárkami,
potom teprve úseky mezi sebou navzájem.

G 86527 - B 39503 - P 68,7 (78,8) vše

Došlo ke zhoršení, proto zase toto opatření ruším.

Jiný problém: Někdy se příliš brzy zavěsí člen koordinace na uzel, na
kterém by později měla viset koordinace celá (například "je
absolventem elektrotechnické fakulty čvut a postgraduálního studia" -
příliš pozdě se spojí "fakulty čvut", takže "fakulty" nevidí svého
koordinovaného sourozence "studia" a spojí se tedy (příliš brzy)
"absolventem fakulty").

Návrh obecného řešení: Ve chvíli, kdy se pod řídící uzel zavěsí nový
závislý uzel, získává řídící uzel nové sousedy. V tu chvíli musí znova
přezkoumat své vlastní zavěšení, pokud už nějaké má. I nyní se bude
omezovat na své sousedy, proto nemůže zavléct do stromu
neprojektivitu.

25.7.2002

Konečně mám odladěnou první verzi výše uvedeného, ale výsledek je
zklamáním (dosavadní maximum je zopakováno ve druhém řádku):

G 87142 - B 38888 - P 69,1 (77,8)
G 88273 - B 37757 - P 70,0 (78,6)
ve skutečnosti naměřeno po vypnutí posledního výmyslu
G 88234 - B 37796 - P 70,0 (78,6)
tj. ještě o 39 závislostí hůře, ale to může být v důsledku chybky
nejen teď, ale i předtím

Opravy již zavěšených uzlů opět zapnuty, ale povinně se ihned po
zrušení závislosti znova zavěšuje odpojený uzel. Velmi nepatrné
zlepšení.

G 87204 - B 38826 - P 69,2 (77,7)

Z dodatečných oprav jsou vyloučeny uzly zavěšené v koordinacích. Zatím
jen velmi nahrubo, pokud je řídícím uzlem "a" a jeho značka nezačíná
na "J".

G 87587 - B 38443 - P 69,5 (77,7)

Pořádná implementace téhož: s využitím globálního pole @coord.

G 87768 - B 38262 - P 69,6 (77,4)



26.7.2002

Ale bude to chtít detailní srovnání analýzy s dodatečnými opravami a
bez nich a porovnání chyb: které zmizely a které přibyly. Zatím počty:

A 15060 ... počet příležitostí, kdy to vůbec šlo zkusit
B  5205 ... počet příležitostí k opravě (do té chvíle to bylo špatně)
            Kdyby se všechny tyto příležitosti využily, byl by
        výsledek analýzy G 93439 - B 32591 - P 74,1. Bohužel se
        využil jen zlomek z nich a naopak se v řadě případů
        podařilo již dobrou analýzu pokazit.

POZOR! Ne vše, čemu výše říkám "příležitost k opravě", musela být
opravdu příležitost. Netestoval jsem, zda správné zavěšení už bylo v
tu chvíli k dispozici. Také není správně odhadnuta úspěšnost, které by
mohlo být dosaženo, protože počítám pokusy o opravu, ale u některých
uzlů mohlo dojít postupně k několika pokusům.

S  4783 ... bylo a zůstalo špatně
L   422 ... podařilo se opravit
D  8506 ... bylo a zůstalo dobře
H  1349 ... podařilo se zkazit

Oprava: dosud při opravě špatně fungovalo omezení povolených
závislostí na opravovaný uzel.

G 87783 - B 38247 - P 69,7 (77,4)
D 8789 - S 4823 - L 460 - H 1051

Spočítány opravdové šance něco opravit, tj. nejenom že v okamžiku
pokusu o opravu byl daný uzel špatně zavěšen, ale že také bylo k
dispozici jeho správné zavěšení. Výsledek:

1497 šancí celkem
1434 uzlů, které šanci dostali aspoň jednou
=> kdyby se všechny šance využily a nic nezkazilo, analýza by skončila
takto:
G 89668 - B 36362 - P 71,1 :-( to je málo...

Závěr: Opravy uzlů tímto způsobem mohou analýzu vylepšit jen o 1,1 %,
což je v této době ještě dost málo. Každé procento je sice dobré, ale
my neumíme zajistit, aby se v průběhu oprav současně nepokazilo něco,
co už bylo dobře. Proto od oprav odstupuji, přinejmenším prozatím.

G 88235 - B 37795 - P 70,0 (78,6)



Pokus: pravděpodobnost závislostí (ne koordinací) násobit doplňkem
pravděpodobnosti, že řídící uzel je koordinační spojkou (zaměřeno
hlavně proti přehnanému věšení uzlů na spojku "a" ještě dříve, než je
k dispozici druhý koordinační člen). Taky nepomáhá:

G 87884 - B 38146 - P 69,7 (79,3)



29.7.2002

Kontrola úseků mezi čárkami přepracována s pomocí pole zakázaných
závislostí. Pravděpodobnost nekoordinačnosti zůstává
zapnuta. Pochopitelně to znamená útlum úspěšnosti. Uvidíme, zda se
později podaří s novou implementací čárkových úseků dostat zpět na
původní úspěšnost.

G 86807 - B 39223 - P 68,9 (80,1)

Vypnuta pravděpodobnost nekoordinačnosti.

G 87078 - B 38952 - P 69,1 (79,7)

Mezičárkové úseky: opět je překročení čárky povoleno ihned, jakmile se
dokončí závislý úsek (viz též pokus 19.7.2002). Tentokrát to ovšem
nepomohlo.

G 86116 - B 39914 - P 68,3 (78,3)

Překročení čárky je povoleno až po sestavení všech úseků, bohužel se
nyní musím spokojit s úspěšností 69,1 % :-(

G 87078 - B 38952 - P 69,1 (79,7)



Pokus: nelze přeskočit předložku závislostí vedoucí zleva doprava,
dokud tato předložka nemá dítě. Opět se používá černá listina $zakaz.

31.7.2002

Výsledky pokusu jsou špatné. Výpočet je třikrát pomalejší (trvá nyní
23:50 minut) a úspěšnost klesla o 1,3 %. (Po návratu k původnímu stavu
program trvá 10:37 minut (dříve to bylo kolem osmi?) a úspěšnost je
opět 69,1 %.)

G 85486 - B 40544 - P 67,8 (74,2)

Poznámka: po přepsání pokusu s předložkami program běžel skoro stejně
dlouho (23:47 minut, což mě překvapuje, protože nová implementace by
měla být efektivnější) a výsledek se nepatrně liší (k lepšímu).

G 85504 - B 40526 - P 67,8 (74,3)

Objevena chyba v přehodnocování zákazů přeskakování předložek. Po
jejím odstranění se program zrychlil na 15:47 minut a zvedla se i
úspěšnost:

G 87512 - B 38518 - P 69,4 (80,5)

Jak analyzovat vliv nového omezení?
1) Spustit parser bez nového omezení a výstup si schovat.
parse.pl
cp analyza.csts vystupy/omezeni-0.csts
2) Spustit parser s novým omezením a výstup si schovat.
parse.pl
cp analyza.csts vystupy/omezeni-1.csts
3) Spustit program pro porovnání výstupů několika různých
parserů. Tento program mj. uloží nový soubor, kde jsou slity výsledky
všech analýz.

2.8.2002

Vyčleněny věty, ve kterých zákaz přeskakování předložek zhoršil
alespoň jednu závislost. Je jich celkem 417. Výsledky, když je
přeskakování předložek zakázáno:

G 6142 - B 3665 - P 62,6 (72,9)

Zazálohoval jsem ladící soubory analyza-debug.csts a analyza.log a
pouštím test s vypnutým zákazem přeskakování předložek.

G 6279 - B 3528 - P 64,0 (74,4)

5.8.2002

Objevena chyba v určování délky hrany, konkrétně zda se mezi uzly
nachází či nenachází čárka. Bez přetrénování došlo ke zhoršení
úspěšnosti (zákaz přeskakování předložek je zapnut). Snad to bude
lepší po přetrénování.

G 87512 - B 38518 - P 69,4 (80,5) před opravou
G 87124 - B 38906 - P 69,1 (80,5) po opravě

Po přetrénování - sláva! -:

G 89639 - B 36391 - P 71,1 (82,5) po přetrénování

Teď ještě zbývá zjistit, jestli to bez zákazu přeskakování předložek
není ještě lepší :-|

6.8.2002

Vypnutím zákazu přeskakování bezdětných předložek se nyní úspěšnost
skutečně zhorší, i když pochopitelně ne na úroveň před odstraněním
chyby.

G 89323 - B 36707 - P 70,9 (81,9)



Vzhledem k objevené chybě se ještě jednou pokusím vyzkoušet násobení
pravděpodobnosti závislosti pravděpodobností toho, že řídící uzel není
koordinační spojkou. Zákaz přeskakování předložek je aktivní.

G 89453 - B 36577 - P 71,0 (82,9) # prst. nekoordinačnosti aktivní
G 89639 - B 36391 - P 71,1 (82,5) # neaktivní

Kupodivu jsem výsledky neaktivní verze nedokázal zreprodukovat a vyšly
o trochu lepší!

G 89684 - B 36346 - P 71,2 (82,5)

Analýza:
88395 správně před i po
 1289 správně pouze před
 1058 správně pouze po
35288 špatně před i po
Kdyby se podařilo získat všechna "správně" najednou, bylo by
P = 72,0 %.
Přechodem z a0 na a1 se zhoršilo 860 vět. Z toho mj. vyplývá, že
průměrná délka zhoršené věty je 26 slov, což je o 10 víc než průměr!
Úspěšnost těchto vět:

G 13934 - B 8179 - P 63,0 (80,4) - a1 (aktivní)
G 14799 - B 7314 - P 66,9 (80,7) - a0 (neaktivní)



8.8.2002

Nový pokus s podmiňováním pravděpodobnosti závislosti četností
závislého uzlu. Platí i u koordinací, přestože koordinace pak má různé
pravděpodobnosti, podle toho, od kterého uzlu se díváme. Nemělo by to
ale vadit, protože ve stejnou chvíli by měly být povoleny pohledy od
obou uzlů, takže prostě vyhraje jen jeden z nich.

G 14206 - B 7907 - P 64,2 (80,3) - a1 aktivní

Vzhledem k mírnému zlepšení zkusíme totéž i pro celá testovací data.

G 89562 - B 36468 - P 71,1 (a1)

Zlepšení je opravdu nepatrné. Zkusíme ještě pro a0 (neaktivní). A pak
zkusíme součty všech událostí, které se dané hrany týkají.



27.9.2002

Podmíněné pravděpodobnosti závislostí, a0 (neaktivní).

G 89103 - B 36927 - P 70,7 (a0)

Opět zapínám a1, tj. nekoordinační závislosti se podmiňují
neschopností řídícího uzlu být koordinační spojkou.

G 89562 - B 36468 - P 71,1 (a1, podm. p.)



!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
MOMENTALNE BOHUZEL MUSIM DELAT POKUSY S NECIM JINYM, ABYCH MOHL NAPSAT
CLANEK DO PBML. PAK SE ALE MUSIM K PRACI Z 8.8. VRATIT, PROTOZE NENI
DOKONCENA!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!



27.9.2002

Hlavní myšlenka článku do PBML: chyby v morfologickém značkování
zvyšují počet chyb syntaktické analýzy. Zjistit, jak velký tento vliv
je, a navrhnout a odzkoušet řešení. Možná řešení: 1) na vstup parsingu
posílat úplnou morfologickou analýzu; 2) opravovat značkování během
parsingu (tím, že se rozhodnu pro nějakou variantu syntaktické stavby,
vylučuji některé varianty značkování); 3) dělat si celé značkování
sám; 4) jako 2 nebo 3, ale vytipovat nejzávažnější chyby (pády
podstatných jmen).

Článek by mohl být také o cizích slovech (Bank of America) a o jiných
rušivých vlivech na parsing (zpracování číslovek, atd. v koordinacích
atd.)



11.10.2002

Nová série pokusů s parsingem na různých zdrojích morfologie (úplná
analýza, automatické zjednoznačnění (HMM, maxent), ruční
zjednoznačnění). Předcházející taková série proběhla v roce 1998 v
Baltimoru na neredukovaných pozičních značkách, PDT 0.5 nehotový,
zhruba 13000 trénovacích a 3500 testovacích vět. Nyní vezmu analytická
trénovací data z PDT 1.0 (přes 70000 vět), z nich oddělím asi 5000
testovacích vět (nevezmu je z části PDT označené jako testovací,
protože potřebuju mít k dispozici i ruční morfologické anotace) a
zbytek ponechám pro trénování.

Původní trénovací data obsahují 1583 souborů ze všech 4 zdrojů. Nyní
je právě každý desátý z těchto souborů zkopírován do mtest dat (158
souborů), zbytek do mtrain (1425 souborů). Zastoupení zdrojů by tedy
mělo zůstat zhruba ve stejných proporcích.

Ze všeho nejdřív musíme zopakovat dosavadní pokus na značkách z
taggeru, protože máme jinou množinu dat, a tedy se asi budou mírně
lišit i výsledky.

Nová trénovací data mají 65847 vět a 1133509 slov. Trénování trvalo
8:38 minut. Nová testovací data mají 7241 vět a 122081 slov. Testování
trvalo 16:30 minut.

G 85968 - B 36113 - P 70,4 (d-d)

Trénování podle ruční morfologie trvalo jen 4:38 minut a soubor se
statistikou má 47 MB místo 63 MB!

G 76697 - B 45384 - P 62,8 (h-h blbě)

To je dost podezřelé! Určitě je tam nějaká chyba! Ano, u redukovaných
značek zmizel druhý znak (pád nebo poddruh). Znova: trénování trvalo
5:37 minut a statistika má 54 MB. Jenže ještě chybí selektivní
lexikalizace značek pro předložky! Napotřetí trvalo trénování 7:26
minut, statistika má 63 MB a na první pohled je v pořádku. Testování
trvalo 15:55 minut. Výsledky:

G 87795 - B 34286 - P 71,9 (h-h)

Nezjednoznačněná morfologie, varianty značek se slepí do jednoho
řetězce, případné duplikáty se odstraní. Trénování trvalo 12:33 minut,
statistika má skoro 90 MB. Testování trvalo 12:17 minut.

G 82498 - B 39583 - P 67,6 (m-m sřetězeně)



18.10.2002

Trénování s nezjednoznačněnou morfologií, ale výskyt nejednoznačně
označkovaného slova se považuje za několik necelých výskytů
jednoznačně označkovaných slov. Trénování trvalo 19:58 minut a
výsledný soubor má 63 MB. Testování trvalo 37:31 minut.

G 87634 - B 34447 - P 71,8 (m-m rozloženě)

Asi byla chyba ve čtení značek, takže to budu muset zopakovat. Teď se
ale zase musím věnovat něčemu jinému.



25.10.2002

Návrat k úplným trénovacím a testovacím datům. Výsledky jsou bohužel o
něco horší, než byly naposledy s touto konfigurací, a nevím proč :-(
Tenkrát bylo P = 71,1 %.

G 89343 - B 36687 - P 70,9

Potřebuji zjistit, jak je to s úspěšností na číslovkách.
Úspěšnost zavěšování číslovek, číslovek s pádem a číslovek bez pádů:

G 2646 - B 789 - P 77,0
G 1184 - B 220 - P 84,3
G 2030 - B 569 - P 72,0

Úspěšnost slov, která měla záviset na číslovkách, na číslovkách
s pádem a na číslovkách bez pádů:

G 1070 - B 542 - P 66,4
G  298 - B 231 - P 56,3
G  771 - B 310 - P 71,3

Nyní přetrénujeme a při čtení překroutíme všechny číslovky, aby visely
pod svým podstatným jménem. V dokumentaci musím zdůraznit, že zatím
nijak neřeším to, že se mi teď do kořene negenitivní fráze může dostat
slovo v genitivu (později to budu muset řešit jako u koordinací
propagací pádu nahoru).

G 89311 - B 36719 - P 70,9

Dokonce mírné zhoršení! Budu se muset podívat, jestli není v programu
nějaká chyba, ale asi to bude tím, že nyní mají negenitivní fráze
genitivní hlavy. Napsat do článku, že to vyžaduje hlubší analýzu
rozdílů v chybách s a bez překroucení.



1.11.2002

Upravuji parser, aby nebyl tak náročný na paměť a mohl běžet i
doma. Základní myšlenka: při trénování se statistika rozdělí na menší
kusy, které se natrénují a uloží samostatně. Analýza pak bude mít dvě
fáze. V té první se postupně vezmou všechny dílčí natrénované
statistiky, projdou se s nimi analyzovaná data a ke každému slovu se
uloží výpis ze statistiky pro všechny jeho potenciální rodiče. Poté se
data projdou ještě jednou, přečtou se uložené hodnoty u jednotlivých
slov a navrhnou se stromy.



14.11.2002

Dotažena do konce první verze rozděleného parseru. Skript train.pl se
změnil jen trochu, zastaví trénink vždy po tolika událostech, kolik
udává proměnná $konfig{split}, uloží natrénovaný díl statistiky,
vyprázdní statistiku v paměti a začne od dalšího trénovacího souboru
nanovo. Skript parse.pl byl však rozdělen na markparse.pl, který
projde testovací data postupně se všemi díly statistik a zapíše přímo
do dat statistiky zjištěné o dotyčné větě, a skript parsemark.pl,
který ještě naposledy projde testovací data, přečte si v každé větě
uložená čísla a na jejich základě vybuduje nejlepší možný strom.

Kvůli rychlosti testuju zatím dělený parsing pouze na jednom
testovacím souboru, lu01.a. Z parsemark jsem vyházel veškeré nadstavby
typu koordinace či lokální konflikty, takže úspěšnost musela
klesnout. Výsledky ukazují v prvním řádku dělený parsing, ve druhém
původní parse.pl (s využitím celé statistiky najednou):

G 286 - B 295 - P 49,2
G 618 - B 301 - P 67,2

Zatím je v programu nějaká chyba, která způsobuje, že se ani nepřiřadí
všechny závislosti. Budu muset zase rychle zavést ladící záznamy.



15.11.2002

Po opravení chyby už se zpracují všechny věty (a všechna slova)
vstupu. Úspěšnost to nepatrně zlepšilo. Spodní řádek opakuje pro
srovnání úspěšnost neděleného parseru na stejných datech.

A 919 - G 466 - B 453 - P 50,7
A 919 - G 618 - B 301 - P 67,2

Předělal jsem markparse tak, aby se ukládaly různé události včetně
koordinací. Parsemark ale teď na chvíli využívá pouze OZZ (bez
lexikalizace) a úspěšnost kupodivu poskočila o hodně.

G 575 - B 344 - P 62,6
G 618 - B 301 - P 67,2

Kombinace OSS a OZZ 1:1.

G 570 - B 349 - P 62,0
G 618 - B 301 - P 67,2

Kombinace OSS a OZZ v poměru $ls:(1-$ls) (0.734375:0.265625).

G 575 - B 344 - P 62,6
G 618 - B 301 - P 67,2

Jednoduché přidání koordinací, zatím bez řady akcí dělaných dříve
(propagace značky členů do koordinační spojky, kontrola povolenosti
partnera, násobení pravděpodobnosti koordinace pravděpodobností, že
slovo v kořeni je koordinační spojkou...)

G 569 - B 350 - P 61,9
G 618 - B 301 - P 67,2

Přidán test, že druhá větev zvažované koordinace je povolena.

G 591 - B 328 - P 64,3
G 618 - B 301 - P 67,2

Přidáno násobení pravděpodobnosti koordinace pravděpodobností
koordinační spojky.

G 585 - B 334 - P 63,7
G 618 - B 301 - P 67,2

Opravena chyba: ztrácela se informace o povinném připojení druhé půlky
koordinace v příštím kole.

G 612 - B 307 - P 66,6
G 618 - B 301 - P 67,2

Přidáno kopírování značky člena koordinace do značky koordinační
spojky. S úspěšností to nehnulo.

G 612 - B 307 - P 66,6
G 618 - B 301 - P 67,2

Přidána kontrola, že jedna koordinační spojka nemůže řídit dvě
koordinace, z nichž jedna stojí "obkročmo" kolem druhé.



21.11.2002

Viz minule, koordinace se hledaly jen pro spojky, které už pro nějakou
koordinaci nebyly využity. První výsledek je s chybou - použití spojky
se označovalo jako $afun = "Coord", jenže $afun se plní už při čtení
vzorového souboru a všechny správné spojky tak byly předem
zablokovány. Druhý výsledek je po úpravě, díky které se použití spojky
označuje jako $afun = "CoordX". Třetí výsledek je jako obvykle z
nerozděleného parseru.

G 581 - B 338 - P 63,2
G 616 - B 303 - P 67,0
G 618 - B 301 - P 67,2



12.12.2002

Snažím se posbírat dochované verze perlového parseru a spojit je pod
CVS (Concurrent Versions System). Motivací je zejména snaha najít
verzi před přestavbou, která uměla 71,7 %, ale sbírám i jiné.

Verze z 1.2.2002, nalezená v zipu v záloze dat doma na
Amazonce. Záznamy z 1.2.2002 potvrzují, že tenkrát bylo 60 % nejlepší
dosažený výsledek.
G 75578 - B 50450 - P 60,0

Verze z 11.10.2002 se trénuje jen na 65847 větách. Podle záznamů z
11.10.2002 šlo o nezjednoznačněnou morfologii sřetězenou do dlouhých značek.
G 82498 - B 39583 - P 67,6
Po přesměrování dat se ovšem výsledky zhorší, protože parser.ini z té
doby ještě neumožňoval přepínat také zdroj morfologie, tj. čtení MMt v
něm bylo nastaveno natvrdo v kódu, ale v "hlavních" datech taková
anotace není. Takže se rozhodovalo náhodně.
G 43983 - B 82047 - P 34,9
Naději skýtá fakt, že parse.pl v této verzi ještě neobsahuje proceduru
ud(). Zkouším tedy v parslib.pl přepnout mzdroj z "MM" na "MD", třeba
se úspěšnost ještě vrátí.

13.12.2002

Verze z 11.10.2002 přetrénována a přetestována na značkách MDt a.
G 89562 - B 36468 - P 71,1
Podařilo se mi tedy najít verzi, která ještě dosahovala zatím nejvyšší
úspěšnosti z 27.9.2002 (kdy jsem musel přerušit vývoj a začít se
věnovat článku do PBML). Předtím se taková úspěšnost objevila už
8.8.2002 při posledním pokusu před odjezdem na Tchaj-wan. Tenkrát šlo
o malé zhoršení, což však zůstalo bez povšimnutí, protože jsem
přecházel od malých dat k velkým. Už 6.8. jsem totiž dosáhl výsledku G
89684 - B 36346 - P 71,2, což bylo pro změnu nevysvětlené zlepšení
oproti výsledku z 5.8. (G 89639 - B 36391 - P 71,1). Ze záznamů
vyplývá, že z 5. na 6. srpna jsem zkoušel zapnout přenásobování
pravděpodobnosti závislosti pravděpodobností nekoordinačnosti řídícího
členu. Tento pokus úspěšnost zhoršil, ale po jeho opětovném vypnutí
vzrostla o něco výše než na původní úroveň! Výsledek z 5. srpna - svým
způsobem poslední stabilní - byl dosažen po zákazu přeskakování dosud
bezdětných předložek a po odstranění nějaké chyby v určování
vzdálenosti uzlů (délky závislosti).

Nyní zkusím na objevenou verzi s úspěšností G 89562 dát commit a poté
ověřit, zda s jiným nastavením nezlepšíme úspěšnost ještě na úroveň
6., nebo aspoň 5. srpna.

Po zapnutí absolutních pravděpodobností (pabs=1):
G 89397 - B 36633 - P 70,9

Po vypnutí pravděpodobnosti nekoordinačnosti (nekoord=0, pabs=1):
G 89537 - B 36493 - P 71,0

Po vypnutí obojího (nekoord=0, pabs=0):
G 89106 - B 36924 - P 70,7

Takže návrat k (nekoord=1, pabs=0):
G 89562 - B 36468 - P 71,1



Pro jistotu ještě jeden cvs commit, potom se přesuneme k novější
verzi. Ta pochází z 25.10.2002 a měla by být tedy po přestavbě
umožňující používat slovníkovou morfologii (a přepínat zdroj
morfologie v parser.ini místo přímo ve zdrojáku).

Úspěšnost verze z 25.10.2002 už je opravdu nižší, tj. přestavbou se
něco ztratilo (mzdroj je MD/a, takže správně by výsledek měl být
stejný jako 11.10.2002):
G 89311 - B 36719 - P 70,9

Ztratilo se 251 závislostí. Zkusíme je najít pomocí rozdílů v
analýzách. Nejdřív ale commitnout - zaevidovat verzi z 25.10., byť
znamená zhoršení.

Verze k 8.8.2002 (11.10.2002) s MDt a nejlepší dochovanou úspěšností
(71,1 %) byla v CVS otagována jako "rel-1". Až najdu chybu a opravím
ji ve verzi z 25.10.2002, nebo až hledání chyby vzdám, mohly by
současné verze souborů z 25.10.2002 dostat tag "rel-2" a revizní číslo
2.0. Soubory *.stat a *.csts by se možná mohly vyhodit z repository,
pokud to ještě jde.

Zkoumám, kde se ztratilo těch 251 závislostí. Ukazuje se, že se liší
natrénované statistiky v obou verzích, problém je tedy už při
tréninku. Diffem na zdrojáky obou verzí zjišťuju, že pravděpodobně jde
o chybu při změnách v parslib.pl. Jednoduchou výměnou podezřelého
regulárního výrazu se sice nic nezměnilo, ale po výměně celého
parslib.pl chyba zmizela (statistiky jsou totožné a úspěšnost je také
na původní úrovni, tj. 71,1 %).

Budu postupovat od starší verze parslib.pl k novější a v průběhu budu
kontrolovat trénink na jednom trénovacím souboru.



2.1.2003

Nalezena a opravena chyba v parslib.pl z 25.10.2002. Dosažena
úspěšnost z 8.8.2002-11.10.2002:

G 89562 - B 36468 - P 71,1



3.1.2003

Všechny verze zachované do 11.12.2002 jsou nyní již převedeny pod
CVS. I verze po 25.10.2002 používají opravený parslib.pl. Zkusím nyní,
zda si úplně poslední verze NEděleného parseru (která ovšem už
existuje paralelně s děleným a sdílí s ním trénovací skript train.pl,
který se o případném dělení dozví pouze z parser.ini) zachovává
úspěšnost 71,1 %.

Oprava parslib.pl: v obnovené verzi chyběla funkce cas() používaná
v děleném parseru, doplněno. Oprava train.pl: četl z parser.ini
velikost bloků pro dělení, ale nevěděl, že velikost 0 znamená zákaz
dělení. Oprava parse.pl: neuměl číst statistiku z pracovní složky;
ztratila se mu procedura vymazat_vetu() (zřejmě byla v chybném
parslib.pl). Také neuměl do této složky zapisovat své výstupy
(analyza.csts, analyza-debug.csts, analyza.log).

G 89562 - B 36468 - P 71,1

Heuréka! Nedělený parser tedy přežil ve své nejlepší verzi a dělený je
možné vyvíjet paralelně, když na něj zrovna bude čas. Potvrzuji stav
CVS.



14.1.2003 Nové Hutě

Dočasně nemůžu použít celá trénovací data, omezuju se na soubory
z Českomoravského Profitu (c*). Testovací data jsem zatím použil
celá, i když kvůli rychlosti je posléze taky omezím. Testování na
celých datech trvalo něco málo přes 1 hodinu.

G 86730 - B 39300 - P 68,8

Menší data: pouze soubory lu*, 2294 vět, 39539 slov. Testování trvá
19:54 minut.

G 27845 - B 11694 - P 70,4



16.1.2003

Test na pouze jednom souboru: lu01.a.

G 632 - B 287 - P 68,8

Když se za pravděpodobnost považuje četnost (slovní četnost
kombinovaná se značkovou četností vahami danými konfigurací, ale
nepřevedená na pravděpodobnost).

G 625 - B 294 - P 68,0

Zhoršení by mělo odpovídat zapnuté absolutní pravděpodobnosti
(konfig{pabs}), kterou v tomto případě nelze vypnout. Hned to
vyzkoušíme: vrátíme se k původní proceduře, ale zapneme pabs.
Jenže ve skutečnosti došlo ke zlepšení. Hm, to nechápu.

G 642 - B 277 - P 69,9

Pouze sečíst slovní a značkovou četnost, ale nevyvažovat je. (Odpovídá
vahám 0,5:0,5.)

G 617 - B 302 - P 67,1

Přidat četnosti slovo-značka a značka-slovo.

G 609 - B 310 - P 66,3

Přidat četnosti neberoucí v úvahu vzdálenost a směr.

G 578 - B 341 - P 62,9



30.1.2003 Praha

Návrat k úplným datům. CVS commit, výsledky stále stejné jako loni v
srpnu, pro osvěžení:

G 89562 - B 36468 - P 71,1

Pokus se zásobníkem stavů (zatím se jen buduje, ale nepoužívá). Někde
bude asi bug, protože nejen že to trvá 1:04 hodiny, ale ještě ke všemu
to nedává stejné výsledky.

G 89295 - B 36735 - P 70,9

Po vypnutí ukládání stavu se úspěšnost vrátila a výpočet trval jen 18
minut.

Když jsem nechal ukládání stavu vypnuté, ale zapnul jsem kolem něj
pokusné přidání a opětovné ubrání závislosti ze stromu, úspěšnost
klesla na 70,9 % - pridat_zavislost() a ubrat_zavislost() tedy
nevracejí parser do původního stavu! Analýza trvala 37 minut.

Naopak když jsem toto přidávání zatrhnul, ale dovolil jsem ukládání
stavů (stále stejných, to není pro hash tak náročné), analýza trvala
21 minut a úspěšnost byla 71,1 %. Dalo by se tedy obejít funkce
pridat_zavislost() a ubrat_zavislost() (např. tak, že bych pro
ukládání pouze přidal ručně do ukládaného seznamu jedno číslo), to asi
nakonec udělám kvůli efektivitě, nicméně chybu v obou funkcích je
nutné najít a opravit.



31.1.2003

Chyba ve funkcích pridat_zavislost() a zrusit_zavislost() opravena
tak, že byla vytvořena třetí funkce zjistit_povol(). Bohužel se
ukazuje, že správně vytvořený seznam povolených závislostí byl ten,
který vedl na nižší úspěšnost. Výsledky ještě nejsou definitivní,
protože na novou funkci se ještě nepřešlo v celém programu. Seznam
povolených se teď nebude průběžně udržovat, nýbrž počítat až před
hledáním nové závislosti. Je to pomalejší jen o málo: celá analýza
trvala necelých 20 minut, oproti včerejším 18 minutám starou metodou.

G 89296 - B 36734 - P 70,9 %

Po úplném odstranění $povol úspěšnost ještě klesla. Asi jsem dosud
náhodou nepovoloval nějaké závislosti, které nebyly dobře. Funkce
zjistit_povol() se teď volá na dvou místech, ale půjde to snížit na
jedno. Analýza trvá 23 minut.

G 89196 - B 36834 - P 70,8 %

Odstranil jsem druhé volání zjistit_povol() ze
zjistit_moznosti_zaveseni(), místo toho se seznam povolených předává
shora z generovat_stavy() přes lokalni_konflikty(). Taky jsem úplně
odstranil proměnné @rspan, @lspan a $soused, ale ty už se v tu chvíli
nikde nepoužívaly. Přesto se pokazilo 9 závislostí. OPRAVIT!

G 89187 - B 36843 - P 70,8 %



3.2.2003

Opět přidáno druhé zjistit_povol(). Chyba zmizela, takže problém nebyl
v @lspan, ale tady!

G 89196 - B 36834 - P 70,8 %

Problém odstraněn, zjistit_povol() se volá jen jednou během přidávání
jedné závislosti, analýza trvá 22 minut na počítači loki. Úspěšnost
zůstává 70,8 %.

Pokusil jsem se přejít na slovníkovou morfologii. Podle pokusů na
náhradních testovacích datech vyčleněných z trénovacích dat (a ovšem
nepoužitých v daném pokusu pro trénink) měla vyjít dokonce lépe než
ruční morfologie, a zřetelně lépe než morfologie z taggeru. Tady to
však tak ani trochu nevypadá. Buď jsem udělal chybu tehdy, nebo teď.

G 82258 - B 43772 - P 65,3



4.2.2003

Vracím se k morfologii z taggeru.
Během dne dělám různé pokusy s větami o délce 5, s předložkami a s
přeskakováním sourozenců. Nic z toho zatím není dotaženo, nicméně mám
výsledky pro tento pokus: N2 nesmí přeskakovat svého sourozence
vlevo. Pokud by to chtěla udělat, tj. pokud mezi ní a zamýšleným
řídícím uzlem leží jiný uzel, který přímo nebo nepřímo nezávisí na ní,
nýbrž na řídícím uzlu, dostane taková závislost pravděpodobnost
0. Výsledek ukazuje, že to mírné zlepšení přináší, a že bych se tedy
přeskakováním měl dále zabývat.

G 89448 - B 36582 - P 71,0

Ještě drobnost. Do manipulace s morfologickými značkami přidána
transformace řadových číslovek na přídavná jména. Zlepšení u třech
slov :-)

G 89451 - B 36579 - P 71,0



5.2.2003

Zjišťuju plodnost kořene. První pokus: po vybudování stromu se zjistí,
kolik dětí má kořen. Pokud jich má více než 2, vybere se koncová
interpunkce a nejpravděpodobnější další dítě, ostatní se odpojí a
připojí jinam. Nevýhody: tento přístup zatím neumožňuje nahradit jedno
sloveso koordinací sloves a obecně nedovoluje ostatním uzlům na změnu
reagovat. Přesto došlo k celkem viditelnému zlepšení. Zhoršila se
ovšem časová náročnost (analýza trvala 32 minut), a to proto, že do
koordinací bylo nutné přidat kontrolu povolenosti druhé hrany. Mělo by
to jít alespoň částečně opravit, protože seznam povolených závislostí
si lze pamatovat a dodat jako parametr.

G 89765 - B 36265 - P 71,2

Druhý pokus: zakázat zavěšení na kořen a na koncovou interpunkci až do
konce. Bohužel se zdá, že tento přístup přinesl víc škody než užitku.

G 89509 - B 36521 - P 71,0

Prozatím tedy návrat zpět:

G 89765 - B 36265 - P 71,2

Přidán již včera vyzkoušený pokus s větami délky 5 (zatím se
rozpoznává pouze vzorec "Praha (pšt) -").

G 89978 - B 36052 - P 71,4



6.2.2002

Pokusy s čárkami a závislostmi na nich. První přiblížení: na čárce
nesmí nic viset, protože pak by to musela být koordinace nebo apozice,
a ta se řeší jinde.

G 90992 - B 35038 - P 72,2

Jupí!!!



13.2.2003

Po nějakém vrtání poklesla úspěšnost. Blbé je, že už si nepamatuju, co
to bylo za pokus. Myslím ale, že šlo o vypnutí lokálních konfliktů,
protože jejich statistika je tentokrát prázdná. Vypnuty byly při
tréninku, při testu ne, ale výsledek je stejný. Byly vypnuty kvůli
nějaké chybě (cyklilo se to), doufal jsem, že třeba úspěšnost spíš
kazí, jejich statistika tomu napovídala. Ovšem ony asi vylepšují
úspěšnost ostatních závislostí...

G 90610 - B 35420 - P 71,9

Lokální konflikty znovuzprovozněny, ale úspěšnost stále není na
původní úrovni. Budu si muset nechat zjistit rozdíly mezi verzí
parseru ze 6.2. a tou dnešní.

G 90833 - B 35197 - P 72,1

Ohledání rozdílů.
parslib.pl ... něco se děje s koordinacemi a s apozicemi (dědění
značek) - s apozicemi se dříve nedělalo nic. Je ovšem otázka, odkud se
tahle funkce volá.
train.pl ... liší se, ale zatím se zdá, že v nepodstatných věcech
(přesunutí mechanické práce kolem otvírání a procházení souborů do
knihovny parslib.pl, přesunutí mazání věty po jejím zpracování tamtéž)

Závěr: nenašel jsem rozdíl, který by mohl způsobovat rozdíl v
úspěšnosti. Zkusím tedy pustit parser ze 6.2., aby se vidělo, zda
vůbec má úspěšnost, kvůli které jsem ho zálohoval. A na výsledek se
přijdu podívat až zítra :-)



14.2.2003

Parser z 6.2.2003 má opravdu úspěšnost 72,2 % (G 90992 - B
35038). Našel jsem chybu, kvůli které přestaly fungovat třetí a další
členy koordinací (bylo nevhodně požadováno povolení přidání budoucí
hrany v okamžiku, kdy přidání nemohlo být povoleno). Po jejím
odstranění se obnovila úspěšnost z 6.2.2003:

G 90992 - B 35038 - P 72,2

Provádím cvs commit a mažu vybalenou verzi z 6.2.2003.
Vylepšena efektivita zjišťování povolených hran v proceduře
zjistit_pravdepodobnost_koordinace(). Bohužel během testování načas
vypadl jeden z disků, takže nelze říct, o kolik se vylepší čas na
analýzu. Teď kvůli výpadku trvala 40 minut. Ověřil jsem však alespoň,
že oprava nezpůsobila nějaké nové chyby, po kterých by poklesla
úspěšnost.

G 90992 - B 35038 - P 72,2



17.2.2003

Konečně dopsán prototyp knihovních funkcí pro dědění morfologických
značek u koordinací a apozic. Otestováno trénování i analýza, zda
nebyly zavlečeny chyby a zejména zda to nepadá. Zatím se ovšem značky
dědí, ale ty zděděné se k ničemu nepoužívají, takže opravdová zkouška
ohněm teprve bude. Trénování trvalo 9:31 minut, analýza trvala 26:40
minut.

G 90992 - B 35038 - P 72,2

Pokus s použitím děděných značek při tréninku na události OZZ, OSZ,
OZS, ZZZ, ZSZ, ZZS a ZPV (pseudovalence), ne na koordinaci (KZZ,
UZZ). A vůbec ne při parsingu. Zatím to přineslo zhoršení, což při
omezenosti použití není až tak divné. Událostí po tréninku je teď
3354115 (víc, dříve pod 3300000), trénování trvá 13:19 minut
(!). Analýza trvá 26 minut.

G 89791 - B 36239 - P 71,2 :-(

Musím zjistit, zda hlavní potíž není v tom, že kvůli chybnému
značkování koordinace leckdy sdružují členy s nekompatibilními
značkami, a ty pak chybně ovlivňují značku celé koordinace i její
vztahy. Zjistit, zda by pomohlo, kdyby se alespoň v kořeni ponechaly
duplikáty značek (tj. nejčastější značka by měla také největší
váhu). To se totiž nyní nedělá, protože mechanismus pro zpracování
seznamu značek počítá se značkami z morfologické analýzy.

Teď se tak dívám... Taky je to možná tím, že se při tréninku
alternativy ve značkách vůbec nerozsekaly! Tam se totiž testuje,
jestli je zdroj morfologie "MM", a to není!



18.2.2003

Vypínám děděné značky, vrátím se k nim za pár týdnů. Teď musím nutně
vytvořit něco, o čem půjde napsat na ACL, a to děděné značky
nejsou. Měla by to být subkategorizace - tentokrát použitá jako
výstupní filtr.

Filtr se bude snažit zabránit tomu, aby více než jedno doplnění
stejného druhu rozvíjelo totéž sloveso, pokud toto sloveso nemá rámec,
který opakování připouští. Netýká se volných doplnění (zejména
příslovečné určení času a místa "kde"). Naopak se to týká podmětu
(lépe: podstatného jména v 1. pádě), i když podměty v rámcích
neevidujeme.

Obecněji: pokud na slovesu visí něco, co vypadá jako vnitřní doplnění,
ale sloveso to nemá v rámci, vyvolat poplach. Možná, že jiné sloveso
si to rádo vezme.

Na druhé straně: pokud to vypadá, že slovesu něco chybí, poohlédnout
se, jestli to v okolí nepřebývá (tj. je to tam a nikdo jiný na tom
nesedí ze subkategorizačních pohnutek). Pokud ano, vyvolat také
poplach. Zjistit, že slovesu něco chybí, není úplně triviální. Znamená
to, že musíme projít všechny jeho rámce a najít takový, kde toho chybí
nejméně. Z prohledávání jsou více méně vyloučeny rámce, které zavrhují
něco, co naopak na slovesu visí (ale ne absolutně: může to tam totiž
viset omylem).

Seznam rámců by mohl být nový, pořízený novým perlovým kódem, hlavně
však z nové verze treebanku, a asi nejen pro slovesa, ale pro všechny
slovní druhy, u kterých se nějaké preference vysledují.



Ovšem po shlédnutí souboru se statistikou usuzuji, že nejdřív by se
mohla vylepšit pseudovalence. Ze slovesné značky by se k heslu mělo
připojit pouze počáteční "V", ale nikoli znak za ním, určující čas a
způsob. A vůbec by se neměl brát ohled na směr a délku závislosti.

V trénovacích datech zaznamenáno 3149779 událostí. Trénování trvalo
11:44 minut.

Úprava pseudovalence: Bohužel jsou výsledky ještě horší :-(

G 88442 - B 37588 - P 70,2

Poddruh ze značky asi nebyl nedůležitý, protože rozlišoval činný rod
od trpného, a ty mají různé rámce. Taky infinitiv a rozkazovací způsob
jsou důležité, protože nemají podmět. Možná by se nemuselo rozlišovat
mezi nimi navzájem, stejně jako mezi přítomně-budoucím a minulým
časem, ale to už jsou asi jen drobnosti.

Zkusím tedy vrátit značku, ale zatím nevrátit směr a délku
závislosti.

Událostí je teď 3178791. Trénování trvalo 9 minut.

G 90613 - B 35417 - P 71,9

Vracím i směr a délku. Opět 3225713 událostí, trénování trvalo 9:40
minut.

G 90992 - B 35038 - P 72,2

Dalším předběžným pokusem by mohl být zákaz přeskakování významového
slovesa kvůli nadřazenému modálnímu slovesu vnitřními doplněními (tedy
pro tyto účely dejme tomu čímkoliv s výjimkou R6 a D). Je to obdoba
již vyzkoušeného zákazu přeskakování N2 jiným N2.

G 90774 - B 35256 - P 72,0

Ruším zákaz, aniž bych v tuto chvíli podrobněji zkoumal, proč to
nefunguje.

G 90992 - B 35038 - P 72,2



19.2.2003

Pokus s valencí. Jestliže na slovesu už visí N1, zakázat zavěšení
druhého N1 na totéž sloveso.

G 90437 - B 35593 - P 71,8

Pokračování pokusu: výše uvedený zákaz se netýká slovesa "být"
(přísudek jmenný se sponou).



5.3.2003

Deadline ACL Sapporo jsem prošvihnul, takže se můžu vrátit k výzkumu
:-) Pro začátek zkontrolujeme, že máme parser ve zdravém stavu, tj. že
dosahuje dosud nejlepší dosažené úspěšnosti 72,2 %.

G 90992 - B 35038 - P 72,2

Dále se podíváme na stav, v jakém bylo zanecháno zpracování koordinací
a apozic. Opustili jsme ho 18.2., naposledy se s ním něco dělo
17.2. Bylo rozchozeno dědění morfologických značek, ale jeho využití
při syntaktické analýze ještě nebylo bezchybné a také zhoršovalo
úspěšnost analýzy.



13.3.2003

Odstraněny nějaké chyby v dědění značek a jeho využití při
tréninku. Úspěšnost se ovšem stále zhoršuje, ale asi mi nezbyde, než
to považovat za nezbytnou drobnost na cestě ke konečnému
vítězství. Ještě nemám prozkoumané detaily, ale číselné výsledky jsou
následující:

G 90465 - B 35565 - P 71,8

Jako obvykle je skutečný příbytek chyb větší, než těch 527 závislostí,
protože na některých místech se analýza na oplátku
zlepšila. Konkrétně:

Počet rozdílných názorů předcházejícího a současného parseru: 5814.
Z tohoto počtu měl starý parser dobře 1570, nový 1043. Nový parser
tedy přinesl 1570 zhoršení a 1043 zlepšení. V názoru na ostatní
závislosti z uvedených 5814 se parsery sice lišily, ale oba ho měly
špatný.



14.3.2003

Práce na notebooku (Intel Celeron 800 MHz, 250 MB paměti, z toho,
zdá se, asi 100 MB využijí Windows ME). Trénink v plné šíři by se
sem nevešel, ale analýza ano, pokud ze statistiky odstraníme všechny
události, které nebyly viděny více než jednou. Velikost souboru se
statistikou klesne ze 67 na 18 MB. Úspěšnost klesne pouze nepatrně:

G 90759 - B 35271 - P 72,0

Přesto asi budu v praxi pro testy používat jen malou část dat,
protože analýza celé množiny trvá dvakrát déle než na lokim: 1:28 h.
Omezíme se na soubory lu* (48 souborů). Jejich analýza trvá 26 min,
což odpovídá době potřebné na lokim k analýze všech dat.

G 29205 - B 10334 - P 73,9

Stejný pokus na stejném počítači, ale pod Linuxem, je jednak delší
(43 minut), jednak má nižší úspěšnost!!! Jediné vysvětlení, které mě
napadá, je, že tento Linux již místo ISO Latin 2 používá Unicode
UTF-8, takže nefungovaly lexikalizované statistiky.

G 28184 - B 11355 - P 71,3

Objevil jsem pravděpodobnou příčinu, proč klesla úspěšnost po
natrénování na zděděných značkách. Změnil se totiž počet závislostí
N1-N1: dříve vítězil směr zleva doprava, nyní zprava doleva. To
znamená, že zděděná značka se dostala do závislosti s tím, kdo ji
zdědil. Například by k tomu mohlo dojít u apozic, protože koordinace
jsou v tréninku už z dřívějška podchyceny, ale apozice ne.

Dále: slova a hesla by se měla dědit stejně jako značky.

Dále: na rozdíl od dřívějšího dědění koordinací nyní dědíme celou
skupinu značek (podobně jako u morfologie ze slovníku). Při evidenci
závislostí už se to využije, ale mělo by se to využít i při evidenci
koordinací a apozic. Nyní by se zaevidovala koordinace vždy, když
řídící uzel má s-značku Coord nebo Apos, a to mezi značkou závislého
uzlu a všemi ostatními značkami v seznamu ve zděděné značce řídícího.



28.3.2003

Návrat na počítač loki (Intel Pentium 4, 1.8 GHz, paměť 1.5 GB).
Kontrola, že parser je ve stavu, v jakém si myslím, že jsem ho
zanechal.

G 90465 - B 35565 - P 71,8

OK, je to stejné jako 13. března před odstěhováním na
notebooka. Analýza trvala 30 minut.

Opraveno: při dědění značek se za člena koordinace neoznačila
předložka, ale podstatné jméno pod ní. Nyní už se označuje
předložka. Přetrénování trvalo 15 minut, zaznamenáno 3301150
událostí.

G 90588 - B 35442 - P 71,9

Opraven způsob, jakým se při trénování oddělovaly závislosti od
koordinací. Dosud se některé koordinace omylem započítaly i do
závislostí, naopak závislosti celých koordinací na něčem se
vynechávaly apod. Nyní při dědění značek současně buduju pro každý
uzel příznak, zda je členem nějaké koordinace, takže by to mělo
fungovat správně (přinejmenším tak správně, jak funguje dědění značek)
a navíc by to nově mělo zahrnovat i apozice. Přetrénování trvalo 18
minut, statistika obsahuje 3222068 událostí (to dává smysl, byl
odstraněn šum chybných událostí).

G 90893 - B 35137 - P 72,1

Nyní jediná další změna: v train.pl se za koordinaci považují nejen
konstrukce řízené uzlem s s-značkou Coord, ale také Apos. Trénování
trvalo 13:30 minut, zjištěno 3225577 událostí.

G 90634 - B 35396 - P 71,9 :-(



31.3.2003

Snažím se využít existenci alternativ u značek
v koordinacích. Opravuji chybu - regulární výraz se nedokáže smířit
se značkou "Z(". Zjištěno 3242983 událostí. Trénování trvalo 11
minut.

G 90465 - B 35565 - P 71,8 ;-((

Je to ale nějaké divné, protože nejčetnější koordinace jsou ty, které
neobsahují partnera. Opravena chyba. Zjištěno 3009050
událostí. Trénování trvalo necelých 11 minut.

G 90420 - B 35610 - P 71,7



3.4.2003

Zahajuji přestavbu parse.pl, která mi umožní paralelně parsovat podle
dvou různých modelů a porovnávat jejich úspěšnost. Současně je to
výtečná příležitost vyčistit po měsíce nabalovaný kód. Dnes už to ale
nestihnu. Zatím jen paralelně běžel pokus s neděděnými značkami. Měl
by dopadnout stejně jako 5.3.2003, ale jedna závislost se někde
ztratila, čert ji vem.

G 90991 - B 35039 - P 72,2



16.4.2003

Dokončení přestavby odloženo na neurčito. Teď udělám jen jednu věc,
budu u každého uzlu vypisovat seznam závislostí, které byly povolené v
okamžiku, kdy byl uzel zavěšen. S pomocí takového výpisu bych měl být
schopen najít chyby způsobené poslední změnou parseru.

Zatím ale musím opravovat parser, aby byl opět provozuschopný, ten
pokus o přestavbu před dvěma týdny ho zjevně dostal do nekorektního
stavu. Test pouštím na ořezané statistice (pouze události, které se
staly více než jednou), takže úspěšnost nebude standardní.

G 90074 - B 35956 - P 71,5
Pouštím tedy ještě totéž na úplné statistice.
G 90252 - B 35778 - P 71,6



9.5.2003

Potvrzen výše uvedený poslední výsledek, aniž bych si ovšem pamatoval,
jakými změnami parametrů k němu došlo (už totiž pamatuju i
lepší). Analýza na lokim trvala 32 minut. Zkouším ji ještě pustit na
shrekovi s lokální kopií dat, ale zrychlení není na pohled nijak
impozantní, trvá to teď 28 minut.

Zkusím se vrátit k verzi před hrátkami s apozicemi. Situaci mi
komplikuje zmizení složky CVSROOT na ÚFALu, ale naštěstí mám nějakou
zálohu z 13.3.2003 na notebooku, tak uvidíme.

Výsledky na současných datech (ovšem těch "normálních", nezískaných na
zděděných značkách), jsou skutečně ty správné.

G 90992 - B 35038 - P 72,2



12.5.2003

Musíme přijít na to, kde je v novém parse.pl chyba, že jeho úspěšnost
je při použití téhož modelu horší. Omezíme test na menší data.

starý: G 672 - B 247 - P 73,1
nový:  G 665 - B 254 - P 72,4

Rozdíly mezi parse.pl a parse1.pl jsou příliš rozsáhlé. Zkusíme
nejdříve zjistit, zda chyba není v parslib.pl. Necháme starý parse.pl,
aby používal nový parslib1.pl.

G 672 - B 247 - P 73,1

Chyba je tedy přímo v parse1.pl. Budu se postupně přesouvat od
parse.pl k parse1.pl. První krok: přidám proceduru rozebrat_vetu(),
aniž bych ji použil.

G 672 - B 247 - P 73,1



13.5.2003

Starší kód nahrazen knihovní (parslib.pl) funkcí
projit_data(). Výsledky zůstávají v pořádku.

G 672 - B 247 - P 73,1



14.5.2003

Zvláštní zpracování vět o pěti slovech posunuto v kódu výš. Úspěšnost
se snížila. Je to asi tím, že na konci z podmínky vypadly nějaké věci,
které se mají dělat i pro pětislovní věty.

G 667 - B 247 - P 73,0

Opraveno.

G 672 - B 247 - P 73,1

Kámen úrazu je spojování kořene s koncovou interpunkcí. Po jeho
přesunutí do funkce generovat_stavy() se zjevně parser začal chovat
jinak (a hůře).

G 665 - B 254 - P 72,4

Opraveno.

G 672 - B 247 - P 73,1

Nakonec přepínám na funkci rozebrat_vetu(). Krátký vzorek zůstává
funkční. Teď tedy pro jistotu otestujeme celá testovací data. Je to v
pořádku, stejně jako výsledky z 5. března!

G 90992 - B 35038 - P 72,2

Přechod ze staršího na novější parse.pl dokončen. Úspěšnost zůstává
nesnížená.

Teď zpět k úspěšnosti koordinací a zděděných značek. Vezme-li se
statistika natrénovaná na zděděných značkách, úspěšnost na lu01
výrazně klesne:

G 660 - B 259 - P 71,8

Teď je ještě potřeba dát do pořádku train.pl. V současném stavu na
73088 větách zjistí 2998340 událostí. Bohužel, tohle není to "správné"
trénování z pohledu testu na lu01.

G 662 - B 257 - P 72,0

V train.pl na řádcích 181 a 182 vyměňuji zděděné značky za
vlastní. Našlo se 2979202 událostí. Úspěšnost na lu01 vzrostla, ale
pořád ještě není train.pl v původní kondici.

G 670 - B 249 - P 72,9



15.5.2003

Pokouším se přepnout do starší verze train.pl, ale asi není dost
stará, protože se v ní také používají zděděné značky. Statistika
obsahuje 2351310 událostí. Výsledek je dost děsivý.

G 506 - B 413 - P 55,1

Ze stejné verze jsem odstranil používání zděděných značek. Statistika
obsahuje 3225713 událostí.

G 672 - B 247 - P 73,1
G 90991 - B 35039 - P 72,2

Ve velkém testu se ztratila jedna závislost. Zkouším train.pl vytažený
z mezitím opraveného CVS. Statistika obsahuje 3225713 událostí a
zřejmě je totožná se statistikou získanou o pokus dříve. Když však
tento train.pl pustím v původním kontextu, tedy zejména s původním
parslib.pl a na původních datech (neobsahují nezjednoznačněnou
morfologickou analýzu), dostanu sice také 3225713 událostí, ale
velikost souboru se statistikou se asi o 10000 bajtů liší.

G 90992 - B 35038 - P 72,2

Pouštím tento starý train.pl se starým parslib.pl, ale s morfologicky
analyzovanými daty (nemělo by to vadit <MMt> se stejně nepoužijí,
použijí se <MDt>). Výsledná statistika je pravděpodobně shodná s
vítěznou (dosahující G 90992).

Pouštím tedy totéž, ale s novým parslib.pl. Statistika obsahuje
3910869 událostí, což je dost divné. Zbytek musím odložit na zítřek.



16.5.2003

V novém parslib.pl se starým parser.ini se nezapnula redukce značek.



21.5.2003

Pokračuju v testování starého train.pl a hledání optimální
konfigurace. V parser.ini, používaném starým train.pl, už přibyl
parametr upravovat_mzn = 1, který si přečte nový parslib.pl. Pouštím
starý train.pl s novým parslib.pl a s parser.ini upraveným výše
uvedeným způsobem. Výstupem bude statistika-md.stat s datem 21.5.2003
a časem něco po 12:28. Statistika obsahuje 3225713 událostí. Velikost
souboru je 68527045, to je ta špatná. Chyba se tedy asi skrývá v
parslib.pl.



22.5.2003

Práce na notebooku. Omezuji trénovací i testovací data na
Českomoravský profit (soubory začínající na "c"). Nalezeno 252
trénovacích souborů. Zpracováno 11300 vět. Nejdelší věta obsahuje
132 slov. Trénování běželo 4:56 minut (další měření: 4:20, 4:18,
4:34). Průměrná doba 272 vteřin, průměrná rychlost 42 vět / s.
Na Amazonce, ale s daty tahanými po síti z Conga, to trvalo 6:20.
Když se netahají data po síti, trvá to 6:19 (musel jsem nicméně
využít síťové služby a připojit si lokální disk jako síťový, ale
hlavní zpomalení stejně nejspíš tkví v procesoru a paměti).
Průměrná rychlost ve Windows 2000 na Amazonce činí 30 vět / s.
Statistika obsahuje 607328 událostí a má 12849 kB.

S použitím starého parslib.pl trvá trénování 5:12 minut. Statistika
obsahuje 607328 událostí a má 12847 kB.

Upravený starý parslib o rozdíl č. 3 (kontrola úspěchu RE na <g> a
<A>). 6:47 minut, 12847 kB. Tento rozdíl tedy roli nehraje.

Starý parslib upraven o rozdíl č. 2 (volitelnost "upravovat_mzn").
7:23 minut, 12847 kB. Tento rozdíl také nehraje roli.

Starý parslib upraven o rozdíl č. 1 (budování $anot[$ord]{mznlist}).
4:51 minut, 12847 kB. Tento rozdíl také nehraje roli. Rozdíl, který
hledáme, není ve funkci zpracovat_slovo(), protože ta už je teď
v obou verzích stejná.

Vyprázdněna funkce transformovat_koordinace().
5:46 minut, 12847 kB. Tento rozdíl také nehraje roli.

Zrušena funkce transformovat_slozene_predlozky().
5:29 minut, 12847 kB. Tento rozdíl také nehraje roli.

Vyměněny vnitřnosti funkce projit_data().
4:58 minut, 12849 kB. Tady někde je ten rozdíl!

Vnitřnosti vráceny, pouze přidána úprava značek koncové interpunkce.
4:49 minut, 12849 kB. To je ono!



23.5.2003

Chyba byla v tom, že se koncová interpunkce označovala dvakrát přes
sebe, jednou v parslib.pl a podruhé v train.pl. Po odstranění
druhého označování z train.pl a ponechání prvního v parslib.pl má
výsledná statistika opět jen 12847 kB. Trénování trvalo 4:52 minut.
Po spojení takto opraveného train.pl s novým parslib.pl zůstává
12847 kB.

Nový train.pl obsahuje jednak svůj nový kód, jednak volitelně
kompletní starý kód. Starý po opravě označování koncové interpunkce
produkuje 12847 kB, nový však stále nemá ani správný počet událostí
(561619 místo 607328).

řádek 141: netestovat Apos, ale jenom Coord
řádek 174: použití $anot[$i]{coordmember}
řádky 183 a 184: použití zděděných značek v závislostních událostech
řádky 206 až 257: podivný else-blok, týká se asi koordinací

Do domácích testovacích dat zařazuji soubory začínající na "lu0".
Celkem 9 souborů, 445 vět, 7901 slov. Testování trvá 6:36 minut.
G 5689 - B 2212 - P 72,0

Pokus s úpravou trénování. Místo na přímé testování, zda já nebo můj
rodič máme funkci Coord, se spoléháme na anotaci coordmember, zjiš-
ťovanou při čtení vstupu. Tato anotace ale zahrnuje i apozice a
neptá se na mého rodiče.
Trénování trvalo 5:09 minut, statistika obsahuje 557955 událostí a
má 11885 kB. Výsledky testu:
G 5697 - B 2204 - P 72,1

V train.pl zavedeny dva rozskoky:
$alt[0] = 0 ... coordmember je dítě kořene koordinace, i kdyby nebylo
                jejím členem
$alt[0] = 1 ... coordmember je člen koordinace, i kdyby nebyl dítětem
                kořene, ale jeho vzdálenějším potomkem (třeba přes
                předložku)
$alt[1] = 0 ... pouze Coord
$alt[1] = 1 ... i Apos se zpracovává jako koordinace

Konfigurace 00 odpovídá starému (a zatím nejúspěšnějšímu) train.pl:
5:10 minut, 607328 událostí, 12847 kB.
G 5689 - B 2212 - P 72,0

Konfigurace 01 (přidat Apos, ale nekomplikovat si život vnořeními):
4:50 minut, 597991 událostí, 12672 kB.
G 5680 - B 2221 - P 71,9

Konfigurace 10 (hlídat vnořené, ale o apozice se nestarat):
4:52 minut, 557955 událostí, 11885 kB.
G 5697 - B 2204 - P 72,1

Konfigurace 11 (hlídat vnořené včetně apozic):
5:06 minut, 555919 událostí, 11845 kB.
G 5700 - B 2201 - P 72,1

$alt[2] = 0 ... vlastní morfologické značky
$alt[2] = 1 ... zděděné morfologické značky

Konfigurace 111 (navíc zděděné značky; nemělo by smysl, kdyby vlastnost
č. 0 (první) byla 0, protože pak by se místa, kde jde o děděné značky,
vynechávala):
5:35 minut, 560668 událostí, 12042 kB.
G 5682 - B 2219 - P 71,9

Konfigurace 1100 (kontrolní; čtvrtá vlastnost pokrývá zatím celý
else blok týkající se koordinací):
5:33 minut, 556348 událostí, 11864 kB.
G 5723 - B 2178 - P 72,4
To je překvapivě dobré. Na druhou stranu až teď se dostaly ke slovu
některé části, které se mají starat o koordinace, však jsem se divil,
že nejsou v provozu. Částečně o koordinace přece bylo postaráno už
dávno. Jen mi nejde do hlavy, že verze 00, která tyto části také
vypíná, by podle mých pokusů měla být ekvivalentní s verzí, která
byla na velkých datech dosud hodnocena jako nejúspěšnější!

Intermezzo: Testuji tentýž train.pl v téže konfiguraci (1100) na
loki s velkými daty. 73088 vět, 2956228 událostí. Trénování trvalo
16:51 minut. Analýza trvala 31:24 minut. Výsledky:
G 90765 - B 35265 - P 72,0



27.5.2003

Pozor, koordinační události se zpracovávají na dvou různých místech:
postaru před závislostmi, nově po závislostech. Současná verze tedy
některé události eviduje dvakrát. Teď jsem celý druhý koordinační
blok zakomentoval a pokouším se zopakovat výsledky pro konfiguraci
0000. Povedlo se. 4:59 minut, 607328 událostí, 12847 kB.

Jednoduchý krůček, koordinační blok jsem přesunul dozadu k tomu
zakomentovanému (je ale o úroveň výš ve vlastní smyčce, to jsem
zachoval). Nemělo by se nic změnit, ale změnilo se :-(. 4:20 minut,
547314 událostí, 11684 kB.

Tak jinak. Zpracování koordinací je na původním místě, ale odstranil
jsem z něj volání funkce transformovat_koordinace(). 4:31 minut,
607328 událostí, 12847 kB. Přišel jsem na to, proč asi hraje roli,
jestli se koordinace zpracovávají před závislostmi, nebo po nich. Ve
starém zpracování koordinací se totiž mění morfologická značka
v kořeni koordinace.

Koordinace přesunuty do samostatné procedury. Kontrolní běh train.pl.
4:43 minut, 606506 událostí (jakto?!), 12836 kB. Opravena chyba
v odkazech. 4:54 minut, 607328 událostí, 12847 kB. Zrušena procedura
evidovat_udalosti() (šlo jen o kopii staré trénovací procedury, už
nepoužívanou). 4:50 minut, 607328 událostí, 12847 kB. Dokončeno
napojování koordinací na volitelné rozskoky pro děděné značky. 5:01
minut, 607328 událostí, 12847 kB.

Další testování, že se zachovala nejen velikost statistiky, ale i
úspěšnost analýzy.
Konfigurace 0000, parse.pl pro všechny pokusy nezměněn.
5:01 minut - 607328 událostí - 12847 kB (neliší se)
6:30 minut - G 5689 - B 2212 - P 72,0 (neliší se)

Konfigurace 1000 (nový způsob rozpoznání člena koordinace):
5:09 minut - 558561 událostí - 11904 kB (liší se od 10 zkouš. minule)
6:05 minut - G 5695 - B 2206 - P 72,1 (o 2 horší než 10 minule)

Konfigurace 0100 (apozice, ale rozpoznání člena postaru):
5:01 minut - 606744 událostí - 12882 kB (liší se)
6:25 minut - G 5675 - B 2226 - P 71,8 (horší o 5)

Konfigurace 1100 (nové rozpoznání člena + apozice):
5:00 minut - 558997 událostí - 11958 kB (liší se)
6:15 minut - G 5674 - B 2227 - P 71,8 (horší o 26)

Konfigurace 1001 (nové rozpoznání člena + zděděné značky v koord):
4:46 minut - 551019 událostí - 11784 kB
6:13 minut - G 5726 - B 2175 - P 72,5 (zatím nejlepší výsledek)

Konfigurace 1010 (nové rozpoznání člena + zděděné značky v závisl):
4:55 minut - 563541 událostí - 12115 kB
6:22 minut - G 5683 - B 2218 - P 71,9

Konfigurace 1011 (nové rozpoznání člena + zděděné všude):
5:16 minut - 552908 událostí - 11872 kB
6:27 minut - G 5683 - B 2218 - P 71,9 (zvláštní: shodný výsledek s 1010, i když statistika je jiná)

Konfigurace 1101 (nové rozpoznání člena + apozice + zděď v koord):
5:16 minut - 551473 událostí - 11851 kB
6:19 minut - G 5717 - B 2184 - P 72,4

Konfigurace 1110 (nové rozpoznání člena + apozice + zděď v závis):
4:55 minut - 564657 událostí - 12180 kB
6:14 minut - G 5667 - B 2234 - P 71,7

Konfigurace 1111 (úplný přechod na apozice a zděděné značky):
4:56 minut - 552929 událostí - 11910 kB
6:15 minut - G 5673 - B 2228 - P 71,8

Závěr: obecně se zdá, že zahrnutí apozic nepomáhá. Ani jejich
vypnutí však samo o sobě nevede k nejvyšší úspěšnosti, přestože
konfigurace 1011 by mi přišla z těch bez apozic ještě jako nejčistší
řešení.



5.6.2003

Opět na lokim s velkými daty. I tady vyzkoušíme několik konfigurací,
ale asi už ne všechny. Konfigurace 1111.
13:45 minut - 2927372 událostí - 63160948 B
31:24 minut - G 90811 - B 35219 - P 72,1



11.6.2003

Konfigurace 0000 (podle posledních zkušeností s velkými daty by to
měla být ta nejlepší).
16:44 minut - 3225713 událostí - 68517516 B
31:46 minut - G 90992 - B 35038 - P 72,2

Konfigurace 1001 (byla nejlepší na malých datech).
12:03 minut - 2928036 událostí - 62868492 B
31:16 minut - G 91256 - B 34774 - P 72,4

NOVÝ NEJLEPŠÍ VÝSLEDEK!
Uklízím rozvrtané verze a potvrdím CVS. Alternativy v train.pl
zůstanou přepínatelné, ale přepínání nepůjde ovládat z konfiguračního
souboru (bude se muset provádět přímo ve zdrojáku) a defaultně zůstane
zapnutá konfigurace 1001, což znamená:
- rozpoznání člena koordinace novým způsobem (poradí si s členem,
  který není bezprostředním dítětem koordinačního kořene, nýbrž je
  zavěšen např. přes předložku)
- apozice se nepovažuje za koordinaci a nijak zvlášť se nezpracovává
- při trénování závislostí se nepoužívají zděděné značky
- při trénování koordinací se naopak zděděné značky používají
Poslední dva body znamenají:

Při zaznamenávání události KZZ (koordinace dvou značek) zjišťujeme
seznam značek mých partnerů ze seznamu zděděných značek kořene
koordinace. Na rozdíl od staršího přístupu by tenhle měl být odolnější
vůči vnořeným koordinacím a předložkám. Dříve se procházely všechny
uzly ve větě, o každém se zjistilo, zda je to člen koordinace, a pokud
byl, jeho značka (ze @znacky) se přidala do @koortypy; zároveň se
přidala KZZ pro něj a všechny již dříve nalezené @koortypy.

Pozoruhodné je, že zřejmě navlas stejné zaznamenávání události KZZ se
děje v bloku zpracovat_vetu() i ve z něj volaném bloku
projit_koordinace(). Musím zjistit, zda je to potřeba kvůli jiným
alternativám, nebo zda se do jedné z kopií běh nikdy nedostane, nebo
zda se dokonce provádějí obě kopie a každá koordinace se zaeviduje
dvakrát!

Skutečně se volají ud(KZZ) na obou místech. Problém ale bude
komplikovanější, protože pokaždé jsou parametry KZZ jiné značky.



12.6.2003

Opraveno ukládání koordinací se špatnými značkami. Zatím neopraveno
dvojí ukládání koordinací. Konfigurace 1001.
13:46 minut - 2927251 událostí - 62851146 B
31:37 minut - G 91320 - B 34710 - P 72,5

Vypnuto druhé ukládání koordinací, první ponecháno.
13:40 minut - 2927054 událostí - 62848982 B
30:59 minut - G 91155 - B 34875 - P 72,3

Nový pokus o popis vítězné konfigurace 1001:
1) Člen koordinace se poznává novým algoritmem, zvládajícím vnořené
koordinace a předložky v koordinacích.
2) Apozice se nepovažují za koordinace a zachází se s nimi jako s páry
obyčejných závislostí.
3) Závislostní události se sestavují z vlastních značek řídícího a
závislého uzlu, nikoli z těch zděděných. Dokonce se zřejmě nedělá ani
to, co se dělalo kdysi, totiž že kořen koordinace bude v závislostech
něčeho na koordinaci či koordinace na něčem zastoupen značkou prvního
nebo posledního člena koordinace. To by byla chyba! Koordinace by v
závislostech měla být reprezentována něčím lepším než značkou spojky.
4) Koordinační události se sestavují novým algoritmem, který vychází
ze zděděných značek kořene. Mj. se tím zajistí správné započítání
vnořených koordinací. (Starý algoritmus procházel všechny uzly věty,
pokud našel člena dané koordinace, spároval ho obousměrně se všemi
dříve nalezenými členy této koordinace. Nový algoritmus páruje jen
jednosměrně, ale zato se všemi členy, tedy i s těmi, kteří ve větě
následují až za právě nalezeným členem.)

Opravena chyba: značka prvního člena koordinace se nekopírovala do
kořene koordinace za účelem sestavování závislostních událostí, kde
něco závisí na koordinaci nebo koordinace závisí na
něčem. (Techničtěji: $alt[2] se nepředávalo do a nepoužívalo v
proceduře projit_koordinace().)

14:00 minut - 2964897 událostí - 63267805 B
32:29 minut - G 89598 - B 36432 - P 71,1

Ach jo. Zas jedna oprava chyby, která totálně zkazí úspěšnost. Zkusíme
tedy ještě jednou zapnout zděděné značky pro koordinace vstupující do
závislostí. Konfigurace 1011.

12:22 minut - 2932518 událostí - 63163328 B
31:01 minut - G 90852 - B 35178 - P 72,1



17.6.2003

Vzhledem k opravám minulý čtvrtek je bohužel na místě opět
zkontrolovat, zda konfigurace 0000 ještě stále dosahuje stejné
úspěšnosti jako kdysi (i když tato úspěšnost už není nejlepší v
historii, lepší úspěšnosti zatím byly dosaženy jen s pomocí chyby, a
tedy omylem a neodůvodněně).

Poznámka 19.6.2003: přibývají další konfigurace, řadím je sestupně
podle úspěšnosti.

Konfigurace 0010.

13:15 minut - 2942371 událostí
29:44 minut - G 91258 - B 34772 - P 72,4

Konfigurace 0011.

13:11 minut - 2943053 událostí
30:47 minut - G 91103 - B 34927 - P 72,3

Konfigurace 0110.

13:01 minut - 2892516 událostí.
30:42 minut - G 91027 - B 35003 - P 72,2

Konfigurace 0000.

15:50 minut - 3225713 událostí
30:20 minut - G 90992 - B 35038 - P 72,2

Konfigurace 1010.

11:34 minut - 2932361 událostí
30:26 minut - G 90966 - B 35064 - P 72,2

Konfigurace 1000.

13:25 minut - 2969063 událostí
31:14 minut - G 90881 - B 35149 - P 72,1

Konfigurace 0100.

12:42 minut - 3216376 událostí
31:43 minut - G 90733 - B 35297 - P 72,0

Konfigurace 1111.

13:12 minut - 2926483 událostí
31:01 minut - G 90713 - B 35317 - P 72,0

Konfigurace 0001.

12:39 minut - 3209963 událostí
30:15 minut - G 89827 - B 36203 - P 71,3

Konfigurace 1001.

13:15 minut - 2964897 událostí
31:58 minut - G 89598 - B 36432 - P 71,1



20.6.2003

Další konfigurace (zbývá jich 6) už nebudu testovat. Nová nejlepší
konfigurace je tedy 0010 s úspěšností 72,4 (91258). Tato konfigurace
znamená, že:
- členství v koordinaci se zjišťuje postaru (tj. chybně!)
- apozice se nepovažují za koordinace
- kořen koordinace jako ř. i z. člen závislostí používá zděděné značky
- v koordinačních událostech se zděděné značky nepoužívají
Nastavím tuto konfiguraci v train.pl a provedu cvs commit, pak ale
znova zapnu i nové zjišťování členství v koordinaci a obětuju dvě
desetiny procenta úspěšnosti ve prospěch správného postupu. Dále se
tedy bude pokračovat s konfigurací 1010, která má úspěšnost 72,2
(90966, což je nepatrně méně, než měla dosavadní 0000).



Zkusíme každou koordinaci (událost KZZ) započítat s dvojnásobkem
skutečné četnosti. Když jsme něco podobného udělali omylem, úspěšnost
se zvýšila; není akorát jisté, že to bylo tímhle a ne ještě nějakou
jinou chybou.

13:25 minut - 2942371 událostí
29:10 minut - G 91763 - B 34267 - P 72,8

To jsou věci... Zkusím tedy, co se stane, když se každá koordinace
započítá třikrát.

13:18 minut - 2942371 událostí
30:14 minut - G 91971 - B 34059 - P 73,0



26.6.2003

Trénuju konfiguraci 1010 (v pátek jsem až do večera měl zapnuto 0010),
nechávám však zapnuto trojnásobné zvýhodnění koordinací proti
závislostem.

12:46 minut - 2932361 událostí
29:45 minut - G 91209 - B 34821 - P 72,4

Pokus: násilná úprava funkce projit_koordinace(). Jestliže má
koordinace jen jednoho člena, vymaže se již zaznamenaná událost KJJ,
nezaznamená se událost KZZ a místo toho se zaznamená závislostní
událost OZZ (jako zástupce; ostatní méně důležité závislostní události
se zatím nezaznamenávají).

11:17 minut - 2861004 událostí
29:43 minut - G 90400 - B 35630 - P 71,7

Nijak slibně to tedy nevypadá. Pokus ruším a jednočetnými koordinacemi
se v této chvíli nebudu dále zabývat.



27.6.2003

POZOR! Nový způsob zjišťování členství v koordinaci je sice v něčem
správnější, ale zase kašle na to, zda mám nebo nemám vypnuté apozice!
Zkouším je zatím natvrdo vypnout v parslib.pl.

13:38 minut - 2963729 událostí.
29:53 minut - G 91235 - B 34795 - P 72,4

Abych mohl vůbec ještě někdy něco upravovat v train.pl, budu muset
alternativy, které jsem v posledních týdnech vytvořil, zase nějak
zkompaktnit a vůbec to celé formálně upravit. Bylo by dobré, kdyby i
tak zůstala možnost alternativy přepínat, ale hlavně je nutné, abych
si nezkazil současnou nejlepší úspěšnost.

Kontrola úspěšnosti:
11:51 minut - 2963729 událostí.
30:07 minut - G 91235 - B 34795 - P 72,4



30.6.2003

Nový druh události KMM udává, že uzel s jistou morfologickou značkou
byl členem koordinace. Po vydělení příslušným počtem událostí UZZ by
měla vzniknout pravděpodobnost zapojení uzlu do koordinace.

Podle očekávání z toho žádný zázrak nevypadl.

G 89526 - B 36504 - P 71,0



1.7.2003

Valence. Návrat k tomu, o čem jsem psal do Taibei. Naposled jsem se
tím zabýval zhruba před rokem, když jsem odevzdával konečnou verzi
článku. Protože tehdy nebylo jisté, zda seznam slovesných valencí z
Philadelphie byl ten nejlepší, ke kterému jsem se v roce 1999 dostal,
pokusím se ho získat znova. Tentokrát přímo perlovým trénovačem,
prostřednictvím událostí nad zděděnými značkami, z celého PDT 1 a pro
všechna slova (nejen slovesa). Budou to události, kde na jedné straně
bude stát heslo řídícího uzlu, na druhé straně abecedně seřazené
zděděné morfologické značky závislých uzlů. Ze závislých uzlů se
tentokrát nebudou uměle vyhazovat podměty (podstatná jména v prvním
pádě). U řídících sloves se za samostatné heslo budou považovat tvary
trpného příčestí, jinak se heslo vždy vezme z morfologické roviny.

18:29 minut - 3231635 událostí, z toho 267906 RAM.

Odbočka, postřeh: přivlastňovací a ukazovací zájmena se odteď budou
při tréninku i při analýze považovat za přídavná jména.

17:20 minut - 3224091 událostí.
30:03 minut - G 91035 - B 34995 - P 72,2

Zhoršení, vracím do původního stavu.

18:43 minut - 3231635 událostí.
30:00 minut - G 91235 - B 34795 - P 72,4

Úspěšnost se vrátila na dosavadní maximum.



2.7.2003

Pokus s krátkými větami. Všechny věty délky 5 slov a méně se při
tréninku zaznamenají jako událost VET <vzor> <strom>, kde vzor bude
posloupnost morfologických značek, zaznamenaná podobně jako rámec
(značky jsou odděleny vlnovkou) a strom bude posloupnost čísel, která
pro každé slovo určí odkazem jeho rodiče. Např.:
VET Rk~A3~N3 0,3,1

13:22 minut - 3235652 událostí, z toho 4018 VET.
29:46 minut - G 91388 - B 34642 - P 72,5

Zkusíme rozšíření na věty o šesti slovech.

16:54 minut - 3237584 událostí, z toho 5950 VET.
30:51 minut - G 91391 - B 34639 - P 72,5

Zlepšení už bylo dost nepatrné a možná by se s ohledem na napáchané
škody mělo raději zůstat u vět do délky 5, ale přesto se zkusíme ještě
podívat na věty o sedmi slovech. Tam už pravděpodobně dojde ke
zhoršení, ale kdo ví...

13:54 minut - 3239777 událostí, z toho 8143 VET.
29:49 minut - G 91491 - B 34539 - P 72,6

Dobrá, zkusíme ještě věty o osmi slovech.

13:42 minut - 3242203 událostí, z toho 10569 VET.
36:16 minut - G 91511 - B 34519 - P 72,6



3.7.2003

Pouštím se do disertace, případné výstupy následujících týdnů se
možná objeví přímo v ní.



8.8.2003

Měl jsem povypínané zpracování koordinací, raději zkontroluju, že
pořád ještě umím dosáhnout té nejvyšší úspěšnosti.

17:21 minut - 3242203 událostí
31:28 minut - G 91539 - B 34491 - P 72.6



2.9.2003

Selektivně lexikalizuji vztažná zájmena (kdo, co, který, jaký, čí,
jenž) heslem. Úspěšnost se zvýšila, ale jen nepatrně.

18:16 minut - 3262065 událostí (011)
33:12 minut - G 91550 - B 34480 - P 72,6

Podobný pokus, ale místo hesla přidávám jen "W" (za "wh").

17:38 minut - 3252683 událostí (013)
34:45 minut - G 91531 - B 34499 - P 72,6

Vracím zpět lexikalizaci heslem. Pokus o rozšíření: lexikalizuji
všechna zájmena, nejen vztažná.

14:29 minut - 3301172 událostí (015)
33:50 minut - G 91555 - B 34475 - P 72,6

Mírnější pokus: lexikalizuji osobní, přivlastňovací, ukazovací a
vztažná (tj. nejběžnější uzavřené třídy). Jde o zájmena začínající na
já, ty, on, my, vy, můj, tvůj, jeho, její, náš, váš, jejich, svůj,
ten, tento, tenhle, onen, takový, týž, tentýž, sám, kdo, co, kter,
jak, čí, jenž. Nastalo sice další mírné zlepšení, ale v cílové verzi
parseru tuto úpravu nenechám, protože je jazykově závislá.

18:22 minut - 3293735 událostí (018)
36:23 minut - G 91561 - B 34469 - P 72,7

Vrácena selektivní lexikalizace všech zájmen. Přidána selektivní
lexikalizace podřadících spojek (dosud se lexikalizovaly pouze spojky
začínající na "že", "aby" a "zda").

21:26 minut - 3316716 událostí (020)
30:09 minut - G 91344 - B 34686 - P 72,5

Selektivní lexikalizace podřadících spojek vrácena do původního stavu.
Přidána selektivní lexikalizace vybraných příslovcí. Jsou vymezena výčtem
přímo ve zdrojáku, ale při troše práce je lze vymezit jazykově nezávisle
pro trénink i test jako taková příslovce (tvary, ne hesla), která se
v trénovacích datech vyskytla alespoň stokrát. Bohužel nejde použít
rozlišení značek Db a Dg, i když většina nejčastějších příslovcí má Db.
Například desáté nejčastější příslovce "více" se účastní konstrukcí, kvůli
kterým stojí za to zkusit lexikalizaci, ale toto příslovce má značku Dg
(protože je to druhý stupeň příslovce "hodně").

9 nejčastějších příslovcí:
1. tak (2101) 2. jak (1638) 3. už (1611) 4. také (1566) 5. již (1344)
6. ještě (1314) 7. včera (1293) 8. tedy (990) 9. pak (952)
5 nejčastějších příslovcí se značkou Dg:
10. více (946) 26. stejně (448) 36. zřejmě (377) 41. často (357)
46. méně (335)

20:37 minut - 3439991 událostí (022)
30:18 minut - G 91944 - B 34086 - P 73,0 (!!!)



3.9.2003

Nový pokus rozchodit subkategorizaci. Pro začátek (číslo pokusu 24) jsem
v parser.ini zapnul valence=1. Načítá se starý philadelphský seznam rámců
z /home/zeman/programy/valence/seznam_ramcu.txt.

G 91837 - B 34193 - P 72,9

Úspěšnost se snížila. Nechce se mi hned teď zkoumat, kde je problém.
Soubor 0 = /home/zeman/data/test.amm, značka = <g>
Soubor 1 = 023.csts, značka = <MDg.*?src="dz".*?>
Soubor 2 = 024.csts, značka = <MDg.*?src="dz".*?>
 91639   0+1+2     (oba dobře)
 33690   0,1+2     (oba stejně špatně)
   198   0,1,2     (oba špatně, každý jinak)
   305   0+1,2     (zhoršení)
   198   0+2,1     (zlepšení)



5.9.2003

Parser vrácen do stavu z 2.9.2003, použit model 033.stat.

G 91944 - B 34086 - P 73,0



8.9.2003

Přestavba. Potřebuju zachovat neredukované značky pro výstup, ale
současný parser si je nepamatuje. Po přestavbě budou všechny anotace
kromě vlastního slovního tvaru uložené v poli hashů @anot. Pak se
budou nové druhy anotací přidávat snadněji. V průběhu přestavby se
budou muset provádět časté kontroly alespoň na prvních 200 větách,
že to ještě funguje. Vzorová analýza (lu0*.csts) má následující
výsledky:

G 5889 - B 2012 - P 74,5

První etapa: $hesla[$i] nahrazena $anot[$i]{heslo}.
parse.pl OK (G 5889)
Druhá etapa: $znacky[$i] nahrazeny $anot[$i]{uznacka},
$mznacky[$i] nahrazeny $anot[$i]{znacka}. To byl trochu větší boj,
snad poslední problém je s krátkými větami, zřejmě se teď ve vzorci
objevuje značka koncové interpunkce s K (třeba Z.K) a v natrénované
statistice to tak není. Zazáplatoval jsem to v parse.pl, ale možná
to zas nebude chodit po novém přetrénování, to se každopádně musí
ověřit! Takže zatím mám ověřeno parse.pl na malých datech
(lu0*.csts). Teď před odchodem pouštím totéž na velkých datech a pak
také train.pl a ještě jednou parse.pl, aby se ověřilo, že se
nepokazil ani trénink.



9.9.2003

Včera podle očekávání zafungovalo upravené parse.pl nad starou statistikou,
ale nezafungovalo po přetrénování. Dnes jsem opět zrušil úpravu a vzorce
krátkých vět tedy vždy mají značku koncové interpunkce rozšířenou o "K".
Bohužel se někam ztratily 3 závislosti.

G 91941 (místo 91944) - B 34089 - P 73,0

Porovnávám statistiky 033 a 055 a logy 042 a 057. Ve statistikách se liší
pouze novější události ARG, ADJ, RAM a VET - některé z nich dříve neměly ve
značce koncové interpunkce na konci "K", a řada z nich dříve neměla v hesle
kořene dvojkříž. Bohužel se tím asi nevysvětluje pokles úspěšnosti. Ze srovnání
logů je vidět, že události KZZ mají pokaždé trochu jiné četnosti. Jak k tomu
ale mohlo dojít, když statistiky se v řádcích KZZ neliší?



15.9.2003

Problém byl způsoben tím, že některé pravděpodobnosti byly závislé na proměnné
$scelkem, což byl buď součet četností všech evidovaných událostí, nebo počet
různých událostí. Když jsme přidali do statistiky události, změnily se některé
pravděpodobnosti a občas to vedlo k výběru jiné závislosti. A to přesto, že
přidané události neměly s jevy, jejichž pravděpodobnost se změnila, vůbec nic
společného!

Řešení: ruším "absolutní pravděpodobnosti" ($konfig{pabs} je v současné
konfiguraci stejně nastaveno na 0), kvůli kterým se $scelkem hlavně používalo.
Tam, kde se $scelkem používalo i při $konfig{pabs}==0, šlo o chybu. A i kdybych
se v budoucnosti chtěl ke $konfig{pabs} vrátit, muselo by se ve jmenovateli
používat nějaké jiné číslo, které se nezmění, pokud se nezmění statistiky,
které se objevují v čitateli.

Upozornění: úspěšnost tím nejspíš ještě více klesne. Zkusíme ji pak pozvednout
dalším umělým zvýhodněním koordinací (třeba že se koordinační události budou
při tréninku zaznamenávat třikrát nebo čtyřikrát).

G 92022 - B 34008 - P 73,0

Tak kupodivu tentokrát úspěšnost naopak mírně překonala dosavadní rekord!
Udělám tedy cvs commit a vrátím se k výzkumu žárlivosti (šlo o to zjistit,
kolikrát parser zavěsil dva žárlivce vedle sebe, kolikrát byl jeden nebo oba
špatně atd.)

S číslováním pokusů začínáme opět znova od začátku, přetrénujeme s jedničkou.

3439995 událostí, 20:43 minut
G 92022 - B 34008 - P 73,0



8.3.2004

Přestavba parse.pl na parse1.pl a řadu modulů. Na souboru lu01 už se
původní i nový parser chovají identicky. Podle výše uvedených záznamů
ze září to však vypadá, že na celých datech jsou pořád ještě
rezervy. Následují výsledky nového parseru (parse1):

G 91933 - B 34097 - P 72,9

Ukazuje se ovšem, že parse.pl je na tom v současné době úplně
stejně. Matně si vzpomínám, že někdy na podzim, kdy jsem nevedl
pořádně záznamy, jsem se rozhodl odstranit nějakou systémovou chybu i
za cenu toho, že momentálně to lehce poškodí úspěšnost.

Přidávám nové moduly do CVS a potvrzuji stav CVS. Prozatím ponechávám
nové verzi jméno parse1 a staré parse. V příští verzi se to asi už
změní.



10.4.2004

Další úprava parse1.pl kvůli znovurozchození subkategorizace.
Počáteční měření mi poskytne srovnání, podle kterého bych měl
poznat, že jsem způsobil chybu. Používám ořezaný model 4013
(chybí události viděné jen jednou nebo méněkrát). Testuju na prvním
souboru lu01.

G 680 - B 239 - P 74,0

Pro začátek přejdu z volání parslib.pl na používání csts.pm.
Současně zruším používání pole @slova.



11.4.2004

Po dni práce se mi podařilo zařídit, aby i upravený parser dával požadovanou
úspěšnost.

G 680 - B 239 - P 74,0



22.4.2004

Pouštím parser na frekim se vší parádou, včetně n-tic. Dává o půl procenta vyšší
úspěšnost než bylo dosud běžné. Odpovídá to tomu, jak si pamatuju účinek n-tic,
ale v tomto záznamu nemůžu najít příslušné číslo, abych zjistil, zda to sedí přesně.

G 92594 - B 33436 - P 73,5 - běh 5031

Účelem dnešní seance je ověřit vliv valence (pravděpodobně zanedbatelný) na úspěšnost
v současných podmínkách. Musí se to totiž napsat do disertace. Modul valence se
kvůli tomu musí oprášit a znovu rozchodit.

G 92532 - B 33498 - P 73,4 - běh 5032



23.4.2004

Pseudoval = 0, valence = 1.

G 92458 - B 33572 - P 73,4 - běh 5033

Pseudoval = 0, valence = 0.

G 92525 - B 33505 - P 73,4 - běh 5034

Tím bylo prozatím učiněno zadost potřebě čísel v disertaci. Teď se vrátím k různým
projevům subkategorizace sloves, konkrétně k přeskakování slovesa závislostí.
V běhu 5031 (viz první včerejší výsledek, G 92594) hledám všechny případy, kdy
nějaká závislost přeskočila sloveso. Dělím je na správné a chybné a hledám takové,
které jsou v drtivé většině případů (> 90 %) chybné. Dělím je podle upravených
značek přeskočeného slovesa, řídícího a závislého uzlu. Nejčetnější chybné jsou:
(vysvětlivky: počet výskytů - procenta chybně/celkem - značka slovesa - řídícího - závislého - 0/1 chybně/správně
168x (91,3%) Vf VB N4 0
120x (90,9%) Vf Vp N4 0
 98x (89,1%) Vf Vp Z, 0
 92x (82,9%) Vf VB Z, 0
 88x (40,2%) Vp #  J^ 0
 87x (92,6%) Vf VB J^ 0
Celkem součet takových přeskočení, která byla chybná ve více než 90 % případů: 4946.
Kdyby se 90 % z těchto případů (4451) přidalo do správných závislostí, byla by
úspěšnost 77 %! Jenže to by vyžadovalo, abych místo zakázané závislosti našel vždy
tu správnou. A to je utopie.

Pokud se nebudu ohlížet na značku závislého uzlu, budou nejčastější opět přeskočené
infinitivy:
852x (89%) Vf VB 0
667x (87%) Vf Vp 0
Celkem součet 90- a víceprocentních: 1796.

Kromě zákazu přeskočení by se dala vyzkoušet i jiná věc. Při trénování bych si
u každé závislosti pamatoval, zda přeskočila sloveso (a popř. také jaké).

Když se zakáže přeskakování pro konkrétní značky, které byly vidět aspoň jednou
a u nichž je přeskok v aspoň 90 % chybný, úspěšnost vzroste. Ale pozor, zatím to
není dvakrát korektní. Seznam zakázaných přeskoků totiž zjišťuju z testovacích
dat!

G 93559 - B 32471 - P 74,2 - freki 5048

Pouštím tedy na frekim test na trénovacích datech. Na výsledném CSTS zkusím vyhledat
nový seznam zakázaných přeskoků. Bude asi zkreslený, protože parser se na trénovacích
datech chová jinak než na testovacích, ale nebude to podvod. Nechce se mi vyčleňovat
zvláštní data a parser přetrénovávat na zbytku, i když na to někdy třeba také dojde.

freki 5050 ... celá trénovací data, zákaz přeskakování vypnut
shrek 5051 ... testovací data, zákaz zapnut, seznam zákazů: nejen slovesa, viděna aspoň 1x
Obojí spadlo, protože Milan něco dělal a odpojil disk, na který se ukládaly výstupy.
Na novém disku pod číslem 14 to nakonec doběhlo (trvá to ovšem kolem hodiny, procházení
všech přeskoků ve třech vnořených smyčkách je dost neefektivní).

G 93764 - B 32266 - P 74,4 - shrek 0014

Trénovací data (znova 5050, teď pod číslem 015).

G 974093 - B 281497 - P 77,6 - 015



26.4.2004

Projdu výstup z parsingu trénovacích dat a zkusím na něm natrénovat zákazy přeskakování.
Získal jsem 5968 různých trojic značek, definujících zákazy (přeskočený, řídící, závislý).
Zahrnuty jsou pouze trojice, které se vyskytly alespoň pětkrát. Zkusím pustit parser
s využitím tohoto seznamu zákazů. Zapínám zákaz přeskakování, vracím cestu k testovacím
datům.

G 93132 - B 32898 - P 73,9 - freki 016 :-(

Chtělo by to přece jen zjistit, jak moc se šidím, když místo vyčleněných dat používám
analýzu trénovacích dat. Natrénovat tedy parser na mtrain datech a pustit ho na mtest
data.

017.stat je statistika natrénovaná na mtrain datech.
freki 018 je analýza mtest dat statistikou 017.
G 89121 - B 32960 - P 73,0 - freki 018

Při té příležitosti jsem poněkud zcivilizoval train.pl, aby už nepoužívalo parslib.pl,
ale csts.pm a parse.pm, a také aby plně přešlo na pole @anot a zapomnělo na @slova,
@struktura a @afun. Nyní přejmenuju parse1.pl na parse.pl a train1.pl na train.pl a
celé to uložím do CVS.

Aktualizoval jsem seznam zakázaných přeskoků (přeskočený-řídící-závislý) podle
018.csts. Jsou tam všechny slovní druhy v takových přeskocích, které se vyskytly
alespoň pětkrát a které byly z 90 % špatně. Celkem seznam pokrývá 22283 přeskočených
uzlů v 018.csts. Nyní otestuju tento seznam zákazů na dtest datech parserem natrénovaným
na train datech (statistika 013.stat).

G 92782 - B 33248 - P 73,6 - T 31:11 min - freki 019

Zpomalení kvůli testování zakázaných přeskoků (složitost n3) se výrazněji neprojevilo,
ale freki je zřejmě nové dělo (4× Intel Xeon 2.8 GHz, 4 GB paměti).

Úspěšnost je ovšem nižší než se seznamem z testovacích dat. Ještě musím otestovat
seznamy zákazů získané ze stejných dat (018.csts), ale s jiným nastavením.

viděno alespoň pětkrát, libovolný slovní druh ... už bylo ......... 019 - G 92782 - B 33248 - P 73,6
viděno alespoň jednou, libovolný slovní druh .... 46264 výskytů ... 020 - G 91375 - B 34655 - P 72,5
viděno alespoň jednou, jen slovesa ..............  5043 výskytů ... 021 - G 92995 - B 33035 - P 73,8
viděno alespoň pětkrát, jen slovesa .............  2698 výskytů ... 022 - G 92995 - B 33035 - P 73,8



27.4.2004

Ještě poslední pokus. Ponecháme přeskoky sloves, které byly viděny alespoň pětkrát,
akorát k nim přidáme tři nejčastější přeskoky jiných uzlů. Jsou to právě ty, které
byly viděny alespoň 200krát:
Z, Vp VB (219)
Z, VB VB (250)
Z, N1 N1 (267)

G 92942 - B 33088 - P 73,7 - freki 023

Není mi jasné, proč je to horší. Těch 736 hran sice nemusí být automaticky dobře,
za prvé v testovacích datech nemusí být stejně časté, za druhé když zakážu jednu
špatnou možnost, ještě to neznamená, že poznám tu správnou. Ale když se to nezlepší,
proč se to dokonce zhorší? Možná kvůli vedlejším účinkům zákazů. Když v určitém
okamžiku zakážu udělat chybu, možná tím blokuju provedení něčeho správného v příštím
kroku, a někdo tomu něčemu správnému pak vyfoukne rybník?

Závěr: necháme ten nejmenší seznam, protože současně patří ke dvěma nejúspěšnějším:
přeskakování sloves, pokud takový přeskok byl k vidění alespoň pětkrát a zároveň
byl s alespoň devadesátiprocentní pravděpodobností chybný.

Potvrzuju novou úspěšnost 73,8 (G 92995) do CVS.

Pokračuju v testování subkategorizace. Nyní se pokusím využít zásobník stavů analýzy.
Na konci analýzy se zjistí, zda má některé sloveso nenaplněný rámec a zda je ve
větě materiál, kterým by ho šlo naplnit. Pokud ano, pokusíme se o to.



28.4.2004

Trochu jsem zcivilizoval ukládání stavů analýzy v modulu rozebrat.pm. Teď kontroluju,
že jsem nepokazil úspěšnost.

G 92995 - B 33075 - P 73,8 - freki 026

OK, potvrzeno, že jsem nic nezkazil.



29.4.2004

Dokončím používání zásobníku stavů v případě, že na konci prvního pokusu o analýzu
nemá některé sloveso naplněný svůj valenční rámec, ačkoli by mohlo. Opravil jsem
ukládání stavů, ještě jednou vyzkouším, že se nic nepokazilo, než začnu uložené
stavy doopravdy používat.

G 92995 - B 33075 - P 73,8 - drak 027 - T 58:50 minut

Úspěšnost se zaplať pánbůh nezměnila, ovšem ukládání stavů zvýšilo časovou náročnost
skoro na dvojnásobek. Ze stejného důvodu také vzrostla paměťová náročnost ze 425 MB
až na 1 GB.

Teď tedy zkusíme uložené stavy opravdu využívat. K tomu je potřeba, aby se balík
záložních stavů z hashe změnil na opravdový zásobník (pole). Hash se nám však také
hodil, protože bylo možné snadno zjistit, zda negenerujeme stav, který už vygenerován
byl. Rozdělíme tedy strukturu stavů na dvě části, hash vygenerovaných stavů a zásobník
nezpracovaných stavů.

generovat_stavy()

Vygeneruje všechny stavy, ke kterým se lze dostat z aktuálního stavu. Vezme v úvahu
seznamy povolených a zakázaných závislostí i v případě, že některá závislost má
přednost bez ohledu na pravděpodobnostní model (např. tzv. valenční závislosti).
Nevezme je v úvahu, pouze pokud má některá závislost absolutní přednost (je to
druhý díl koordinace apod.) Nové stavy jsou stavy se vším všudy, jako kdyby se
výpočet opravdu měl ubírat tímto směrem. Nová závislost je tedy přidána do stromu,
její váha je známá a je promítnuta do ohodnocení celého stromu. Navíc se ví, jaký
je poměr mezi váhou této závislosti a váhou vítězné závislosti v tomto kole (např.
90 %, ale může to být i přes 100 %, pokud nějaká závislost vyhrála díky protekci,
třeba protože je valenční). Průchod tedy musí být dvoukolový, nejdříve se vygenerují
všechny možné pokračovací stavy včetně vah, potom se zjistí, který stav vyhraje,
a k ostatním se dopočítá jejich procentuální odstup.

Funkce generovat_stavy() dostane aktuální stav a vrátí všechny stavy, ke kterým
se z něj dá dojít. Označí také stav, který podle ní má zvítězit v tomto kole (jak
vyplývá z předcházejícího odstavce, nemůžeme se spolehnout na to, že to bude stav
se 100 % poměrem k vítězi).

Funkce generovat_stavy() neví o celkové evidenci vygenerovaných a zpracovaných
stavů. Ani tedy nekontroluje, zda nenagenerovala nějaký stav, který už nageneroval
někdo jiný. To všechno musí zajistit nějaká obálka - funkce, která ji volá. Možná
ale ještě změním názor a obě činnosti nějak spojím.

obálka

Nechat si vygenerovat nové stavy z aktuálního stavu.
Vyjmout z nich vítěze kola, ten už má jisté, že se stane příštím aktuálním stavem.
Z ostatních vyřadit takové, jejichž strom už byl někdy vygenerován (bez ohledu na to, zda už byly i zpracovány).
Zbývající stavy přidat do přehledu stavů. Přehled seřadit podle poměru stavu k vítězi jeho kola. (Kvůli tomuto řazení
není možné označit přehled ani za zásobník, ani za frontu.)
Přehled stavů je potřeba udržovat v rozumné velikosti. Oříznout ho na n^2 stavů, kde n je počet slov ve větě.



7.5.2004

Přestavba kódu je z větší části dopsána, může se začít ladit. Nejdřív ale raději
zkusím nechat v chodu starou funkci generovat_stavy() a použít jen několik nových
nezbytných drobností. Funkce pridat_zavislost() a zrusit_zavislost() jsou přestěhovány
do nového modulu stav a jsou do nich přesunuty i některé části okolního kódu, které
dříve ležely v rozebrat_vetu(). A zděděné upravené morfologické značky už nepřepisují
původní značky v kořenech koordinací, nýbrž se zapisují do stavu. Z něj se potom
vyzvedávají až v modulu model, když se zjišťují pravděpodobnosti.

Nový kód funguje jen na 53 %. Starý kupodivu taky, protože se snaží používat některé
nové verze knihoven. Zjišťuju, že některé knihovny nejsou přidány do CVS! To se
musí napravit. Naštěstí se mi podařilo sestavit verzi, která zvládá původních 73,8 %
(G 92955). Šup s ní do CVS :-).



10.5.2004

Teď je potřeba zjistit, proč nová verze nefunguje.



11.5.2004

Postupně jsem opravil rozebrat.pm, přesunul jsem funkce pridat_zavislost() a zrusit_zavislost()
do nového modulu stav.pm, zrušil jsem Viterbiho a celý modul rozebrat.pm jsem pročistil.
Při vytvoření koordinace už neměním původní $anot->[$i]{uznacka}, ale ukládám průběžně
měněné značky do $stav->{uznck}[$i]. Tím si uvolňuju ruce, abych se mohl kdykoli
vrátit k nějakému staršímu stavu analýzy, ale navíc se ukázalo, že model n-tic až
doteď dostával poškozené uznacky. Po opravě stoupla maximální úspěšnost, což jsem
také okamžitě potvrdil do CVS.

G 93709 - B 32321 - P 74,4 % - T 20:50 (geri 83) => skoro 6 vět za vteřinu

Nyní se vrátíme k přestavbě započaté 7.5.2004. Zbývá asi jen vyměnit modul genstav.pm.
Bohužel se mi ho nedaří přimět ke stejnému výkonu jako původní genstav.pm, ten
nový zvládá jen 70,0 % (G 88273). Navíc mu to trvá příšerně dlouho (52:51 minut).
Zkusím to udělat znova a postupně. Teď se vrátím k původnímu genstav.pm a doufám,
že také k úspěšnosti 74,4 %. Navíc zruším adresář staraverze a vše zase přestěhuju
do původní složky.

geri 111

G 93708, to je sice chyba jen o jedinou závislost, ale nelíbí se mi to. Rozbaluju
cvs checkout do složky staraverze a pouštím analýzu znova.

geri 112

G 93709, takže CVS záloha funguje. Budu si muset pohrát s jejím sloučením s upravovanou
verzí.

geri 113 je nová verze (v horní složce), změněny moduly rozebrat, genstav a stav
(přinejmenším), evidují se viděné stromy, ale neschovávají se k nim celé stavy
a nic se s nimi nedělá. Evidence lesů dosahuje špiček mezi 1000 a 2000 prvků a zdá
se, že nijak viditelně nezatěžuje paměť, protože zatím také ke stromu neuchováváme
žádná velká data.

G 93708

geri 114 je stará verze (v dolní složce), kam jsem však shora zkopíroval stav.pm.
V novém stav.pm chybějí funkce ulozit_stavy() a odfajfkovat_stavy(), které by se
neměly nikde používat. Chybí tam také funkce zkopirovat_stav(), což doufám také
nevadí. Naopak přibylo pořádné a opravdu hloubkové duplikování stavů, ale ani to
se zatím nikde nevyužívá.

G 93709

freki 115 se od předcházejícího liší tím, že z nové verze sem byl zkopírován i
genstav.pm.

G 93709

freki 116 má navíc nový rozebrat.pm, čímž by měl být kompletní (až na zaznam.txt).
Uvidíme, zda dosáhne G 93709.

G 93709



12.5.2004

Našel jsem rozdíl v parser.ini. V tom horším bylo už zapnuto valence1 = 1. Zkouším
ho vypnout, jestli to pomůže. Mimochodem, mezi dobrou a vadnou verzí jsou celkem
3 odchylky v analýze, ale jen jedna z nich zhoršila úspěšnost.

G 93708 - freki 117

Nepomohlo to. Dochází mi trpělivost a provádím cvs checkout do horní složky. Snad
pomůže aspoň tohle.

G 93708 - freki 118

Poslední pokus. Zrušeny rozdíly v povol.pm a zakaz.pm. Sláva!

G 93709 - freki 119

Sláva!

Pokouším se zcela začlenit učení n-tic do train.pl. Zatím zkusím přidat model n-tic
do statistiky, aniž bych ho použil (bude se ještě stále načítat z textových souborů
ležících vedle), a zkusím kontrolně pustit analýzu, zda s novou statistikou bude
stejně úspěšná. Trénink se jmenuje freki 120.

Musí se dost šetřit pamětí. Pokud se totiž kromě standardních 3 000 000 trénovacích
událostí ještě najednou evidují všechny n-tice pro n=2 až 10, požere train.pl neuvěřitelných
2,6 GB! V trénovacích datech je 5 308 978 n-tic, po profiltrování jich ovšem přežije
jen 7934. Trénování na frekim (Intel Xeon 2,8 GHz) nyní trvá 32 minut.

Zkusíme, jestli se s takto natrénovanou statistikou dá analyzovat stejně úspěšně
jako dosud. Neměl by to být problém, protože jediný rozdíl by mělo být 7000 nových
řádků, které se zatím k ničemu nepoužívají.



13.5.2004

freki 127 běží nad statistikou 124.stat, která by se od 013.stat měla lišit právě
přidanými n-ticemi. Původní textové soubory ještě leží ve stejné složce, ale hned
pustím další kontrolní test, který už opravdu nebude mít šanci je najít. freki 128
Bohužel, oba mají neuspokojivé výsledky. (Oba stejné.)

G 92496 - B 33534 - P 73,4 - T 23:39

Možná je ale i jiný problém, možná je nějaká chyba v tréninku a jakákoliv nově
natrénovaná statistika dá horší výsledky než 013.stat. Uvedu tedy parse.pl i ntice.pm
do původního stavu, ale pustím je stejně na 124.stat.

G 92202 - B 33828 - P 73,2 - T 22:19 - freki 129

Musím zkontrolovat, jestli ještě pořád drží úspěšnost alespoň na 013.stat.

freki 130

124.stat se liší od 013.stat. Od 013 se nezachoval záznam konfigurace, který by
bylo možné porovnat se současnou konfigurací. 013 má datum 3.2.2004 13:22:41,
takže v případě nezbytnosti zkusím sáhnout do CVS.



14.5.2004

Zjistit, proč train.pl neukládá konfiguraci, se kterou byl spuštěn. Opraveno,
sakura 134 už by si měla zachovat uloženou konfiguraci. V train.pl také opravena
událost KJ3, aby se ve statistice místo slovního tvaru neobjevoval "HASH". Přesto
stále train.pl negeneruje stejnou statistiku jako train0.pl z 15.9.2003 (poslední
CVS train před vyrobením statistiky 013.stat 3.2.2004; následující verze 2.13 už
vznikla 8.3.2003). A dále ani train0.pl negeneruje statistiku shodnou s 013, takže
už "optimum" možná nikdy nezrekonstruuju.

Rekapitulace statistik:
013.stat (3.2.2004) ... optimální stav co do úspěšnosti parsingu, chci se k němu
    dostat, ale nevím jak. Nezachovalo se nastavení ani zdroják trénovače.
132.stat (14.5.2004) ... vyrobil train0.pl z 15.9.2003. Nad 132 puštěn parser
    (sakura 133), ale ani ten nemá požadovanou úspěšnost. Má jen G 92499 (73,4 %).
138.stat (14.5.2004) ... nejnovější train.pl, obě výše uvedené chyby opraveny.

013.stat má 70400220 B, 3186784 událostí (řádků). Obsahuje 108933 událostí USS.
132.stat má 76127819 B, 3439995 událostí (řádků). Obsahuje 115479 událostí USS.
138.stat má 75947290 B, 3418684 událostí (řádků). Obsahuje 115479 událostí USS.

Skoro to vypadá, že 013 byl natrénován na jiných datech? Srovnáme-li pouze události
USS ve statistikách 013 a 138, zdá se (pohledem na první stránku diffu), že 138
má všechna čísla větší nebo rovna číslům z 013, a navíc má některá slova úplně
nová. Např. slovo "abdikovali". A to je důkaz! 013 vzniklo natrénováním na mtrainu!
Zkusíme na mtrainu natrénovat novou statistiku (jak pomocí train0.pl, tak pomocí
train.pl).

sakura 139 ... train0.pl na mtrain.csts
drak 140 ..... train.pl na mtrain.csts

139.stat má 70400220 B, 3186784 událostí. Obsahuje 108933 událostí USS.
140.stat má 70243916 B, 3167576 událostí. Obsahuje 108933 událostí USS.

Teď tedy zkusíme parsing nad oběma novými statistikami.

G 92398 - B 33632 - P 73,3 - T 45:19 - loki 141 ....... nad 139.stat
G 92096 - B 33934 - P 73,1 - T 22:23 - belzebub 143 ... nad 140.stat

Ještě jednou testuju úspěšnost nad statistikou 013. Už mě to unavuje, ale zdá se
podezřelé, že by se lišila od statistiky 139, když jsou přesně stejně velké. A
přitom tentýž parser na jedné z nich funguje na 73,3 % a na druhé údajně na 74,4 %.
Teď mi diff potvrdil, že obě statistiky se vůbec nijak neliší! A z průběžných výsledků
to vypadá, že i na 013 výkon nějak poklesl.



25.5.2004

Vracím se k parsingu po narození Lucinky.
Test drak 150 nad statistikou 013. Kontrola, zda dosáhneme nejlepší známé úspěšnosti.
Optimum bylo dosaženo 11.5.2004 a činí 74,4 % (G 93709).

G 93709 - B 32321 - P 74,4 - T 30:27

Test drak 152 nad statistikou 139. Statistiky 013 a 139 jsou totožné, takže by
výsledek 152 měl být stejný jako 150.

G 93709 - B 32321 - P 74,4 - T 30:16

Test anette 153 nad statistikou 013. "Stará verze parseru", tj. poslední verze
uložená v CVS.

G 93709 - B 32321 - P 74,4 - T 26:02

Teď se soustředím na to, aby train.pl uměl vyrobit statistiku totožnou s 013.stat.
Verze z 15.9.2003 to zřejmě umí (použil jsem ji 14.5.2004 a vznikla statistika
139, která je s 013 totožná). Pro jistotu ještě jednou pustím train0.pl, což je
kopie verze z 15.9.2003, i když už má jiné datum. Je to train anette 154, trénuje
se na mtrain datech (1425 souborů).

3186784 událostí - T 10:33 - 154.stat se shoduje s 013.stat

Paralelně pouštím i novější train.pl, opět jen pro kontrolu, protože vím, že tvoří
odlišnou statistiku. Je to train drak 155, rovněž se trénuje na mtrain datech.
Asi po hodině práce to spadlo, protože to nenašlo funkci ntice::shrnout().

Prozkoumám rozdíly mezi train0.pl a train.pl a také rozdíly mezi oběma statistikami.
Vytvářím přechodový skript train05.pl a budu průběžně testovat, zda ještě dosahuje
stejných výsledků jako train0.pl. Nejdřív sjednocuji "use" moduly v záhlaví a odstraňuji
sáhodlouhý "pod" komentář. Je to train anette 156.

3186784 událostí - T 10:38 - 156.stat se shoduje s 013.stat

Nahradím čtení subkategorizačního slovníku analogickou funkcí z modulu subkat.
Je to train anette 157.

3186784 událostí - T 10:34 - 157.stat se shoduje s 013.stat

Provedu všechny úpravy, které nejsou závislé na nahrazení parslib.pl modulem csts.pm.
Vesměs jsou jen kosmetické. Trénování ntic zatím taky nepřidám. Rozdílový soubor
obou trainů má pořád ještě 470 řádků. Test momentálního train05.pl je anette 158.

3186784 událostí - T 10:44 - 158.stat se shoduje s 013.stat

Nahradím pole $struktura[$i] polem $anot->[$i]{rodic_vzor}. Položka rodic_vzor
se plní už i v parslib.pl, takže by neměl vzniknout problém. Je to train anette 159.
Bohužel se zřejmě zacyklil. Cyklení způsobuje $struktura[$k] na řádku 441. Zatím
nevím proč a pouštím train05, kde je tento řádek postaru, všechny ostatní struktury
jsou přepsány pomocí anot. Je to train anette 168.

3192325 událostí (!!!) - T 10:59 - 168.stat se od těch předchozích liší!

Mezitím jsem zařídil, aby $anot->[0]{rodic_vzor} bylo 0 stejně jako $struktura[0].
Mělo by tím odpadnout cyklení a možná také rozdíly mezi statistikami, uvidíme.
Je to train anette 172.

3191989 událostí - T 11:07 - 172.stat se liší od 013.stat.

Liší se události typu LOK a RAM. "Normální" události se neliší. Proto největší
podezření padá na změny ve funkci spocitat_lokalni_konflikty(). Kromě náhrady
$struktury $anotem jsem ještě zpřísňoval podmínku na řádku 634 o $i<$#{$anot}.
Toto zpřísnění teď zakomentovávám a pouštím train anette 174.

3186448 událostí - T 11:00 - 174.stat se liší od 013.stat i od 172.stat.

Od 013.stat se liší méně než 172.stat. Události typu LOK už jsou v pořádku, liší
se pouze události typu RAM. Na těch by sice nezáleželo, protože momentálně se,
pokud vím, při parsingu nepoužívají, ale potřebuju vědět, že umím vyrobit statistiku
totožnou s 013, takže se pokusím opravit i je. To je train anette 175.

3186784 událostí - T 10:49 - 175.stat se shoduje s 013.stat.

Nahradím pole $afun[$i] polem $anot->[$i]{afun}. Kvůli tomu upravuji parslib.pl,
aby při čtení vyplňoval afuny do @anot. Train anette 176.

3186784 událostí - T 11:08 - 176.stat se shoduje s 013.stat.

Nahradím pole $slova[$i] polem $anot->[$i]{slovo}. Kvůli tomu upravuji parslib.pl,
aby obsah obou polí byl opravdu totožný. Zatím se totiž u @anot nevyplňoval kořen
a u žádného slova se nenahrazovala velká písmena malými. Bohužel se to zase někde
cyklí. Grrr! A zase je to v lokálních konfliktech! Je to záludná chyba, neoprávněnými
přístupy za hranici pole @anot se toto pole natahovalo, což mělo fatální důsledky
pro cyklus, který byl délkou pole řízen. Chybu jsem nenašel, raději jsem tedy na
začátku funkce délku pole zkopíroval, pak jsem se ve všech cyklech ptal na délku
kopie a na konci jsem kopii zkopíroval zpět do poškozeného pole. Train anette 192.

3186784 událostí - T 10:57 - 192.stat se shoduje s 013.stat.

Po odstranění polí @struktura, @afun a @slova upravuji poslední související řádky,
zejména volání funkcí, ve kterých se dříve tato pole používala. Train anette 193.

3186784 událostí - T 13:04 - 193.stat se shoduje s 013.stat.

Zdá se, že nyní je již vše připraveno k přepojení z parslib.pl na csts.pm. Provedu
tedy vlastní přepojení. Train anette 194.

3158211 událostí - T 21:14 - 194.stat se liší od 013.stat :-(



27.5.2004

Pouštím parsing nad statistikou 194. Předpokládám, že výsledek bude horší než nad
013. Parse anette 195.

G 93643 - B 32387 - P 74,3 - T 27:34



31.5.2004

Porovnávám statistiky 013 a 194. Liší se snad ve všech událostech. Porovnávám pořadí
výskytu událostí v train03.pl (používá parslib.pl) a train05.pl (používá csts.pm).
Rozdíl je v kořenech koordinací. Starší program má v $anot->[$koren]{uznacka} značku
kořenového slova nebo interpunkce. Novější program tam má množinu značek zděděných
od členů koordinace.

train anette 196: train03.pl se záznamem událostí
train anette 197: train05.pl se záznamem událostí
... až po anette 230

Zdá se, že jsem konečně našel všechny rozdíly v hledání zděděných značek. Pouštím
nový kompletní trénink train05 (anette 231).

3186784 událostí - T 30:31 - 231.stat má sice stejný počet událostí jako 013.stat,
ale neshodují se! Taky velikost souborů se liší: 013 má 70400220 B, 231 má 72137493 B.
Ale to by mohlo být tím, že jsem při ladění změnil OSS na OSSXXX. Dám to do pořádku
a odstraním všechny výpisy do souboru "ud", čímž by se taky měl program o třetinu
urychlit. Train anette 232.

3186784 událostí - T 20:28 - 232.stat se shoduje s 013.stat.

Po 19 dnech se mi tedy konečně podařilo modernizovat kód train.pl, aniž by se to
podepsalo na generovaných statistikách. Pro tuto chvíli ovšem rezignuju na nápad,
kvůli kterému to celé začalo, totiž na začlenění modelu ntic do běžného tréninku.
Jednak už nemám na takové blbosti čas, jednak by to nebylo jen tak, protože ntice
vyžadují posbírat obrovské množství nových událostí, z nichž lze malý cílový vzorek
odfiltrovat teprve na konci, kdy už se ví, která událost byla viděna více než jednou.
Tím se několikanásobně zvyšuje paměťová náročnost programu (z několika stovek MB
až na asi 2 GB) i čas potřebný na výpočet (asi dvakrát).

Zakomentovávám tedy řádek s "ntice::ucit()", kopíruji train05.pl do train.pl, mažu
všechny mezistupně trainNN.pl a potvrzuji cvs commit. Potom ještě naposledy volám
kontrolní "train.pl ; parse.pl" a jdu domů :-)



1.6.2004

Oba závěrečné pokusy dopadly dobře. Trénink trval 10:46 minut.

G 93709 - B 32321 - P 74,4 - T 25:31

Teď se pokusím opravit chybu v train.pl, kterou jsem objevil při jeho modernizaci,
ale nemohl jsem s ní nic dělat, protože bych nedostal totožnou statistiku. Bohužel
není zaručeno, že opravou chyby úspěšnost stoupne a ne naopak klesne.

Stejně je dost divné, že lokální konflikty, kterých se ta chyba týká, se dosud podílely
na lepší úspěšnosti (protože když jsem je vypnul, úspěšnost klesla), přestože sama
slova, která byla při lokálních konfliktech převěšena, dopadla bídně: 1286 zlepšení
proti 2137 zhoršením. Tato bilance byla zřejmě zvrácena nepřímými vlivy, např. že
jiné zavěšení uzlu v lokálním konfliktu působilo jako prevence několika dalších chyb.

train anette 235: 3192797 událostí - T 11:18
G 93717 - B 32313 - P 74,4 - T 25:39 - parse anette 236

Sláva, úspěšnost neklesla, i když stoupla jen nepatrně. Ani bilance lokálních konfliktů
se nezměnila nijak dramaticky: 1297 zlepšení proti 2145 zhoršením. Cvs commit.



Je na čase vrátit se ke snahám o vybudování zásobníku stavů a o vracení se v případě
nenaplněného valenčního rámce. Naposledy jsem se o něco tímto směrem pokoušel 11.5.2004.
Nějaká představa, jak jsem to chtěl dělat, je popsaná u 29.4.2004, ale stejně si
nejsem jistý, že tahle představa nepadla při konfrontaci s realitou.

V modulu genstav.pm jsou nyní dvě verze klíčové funkce. V provozu je zatím stále
stará verze pod názvem generovat_stavy(). Nová verze se jmenuje generovat_stavy1()
a nevrací vítězného kandidáta, nýbrž seznam nových stavů, ze kterých se až pak
musí vybrat vítěz.

anette 238: generovat_stavy() už opravdu částečně generuje nové stavy, ale ty ještě
nemají vliv na výběr vítěze. Jde tedy jen o potvrzovací běh, že se nic neposralo.
Úspěšnost sice zůstala nedotčena, ale výpočet trvá skoro čtyřikrát déle!

G 93717 - B 32313 - P 74,4 - T 1:36:08

belzebub 249: O krok dál. Z nových stavů už i vybírám vítěze a kontroluju, že se
shoduje s vítězem, kterého vybral starý kód. Pokud ne, hodí se výjimka.
-> genstav1.pm (genstav0.pm je původní z CVS)

G 93717 - B 32313 - P 74,4 - T 1:22:49

anette 254: Výběr vítěze z nových stavů obohacen o lokální konflikty. Shoda se
kontroluje až potom.
-> genstav2.pm

G 93717 - B 32313 - P 74,4 - T 1:35:12

Nemáme sice na nový kód převedeno celé generování nového stavu, ale jeho podstatnou
část ano. Nyní změním způsob, jakým se výsledek funkce generovat_stavy() předává
nahoru. Dosud se vracel "max-hash", kde kandidáta popisovaly hodnoty r, z, c, p
a priste. Nyní se bude vracet pole stavů, jehož první prvek bude ten vítězný. Vítězný
kandidát už do něj bude zanesen, tj. u volajícího odpadne následné volání funkce
stav::pridat_zavislost(). Zatím se budou vracet stavy nalezené starým kódem.

belzebub 262 (výše uvedené)
G 93717 - B 32313 - P 74,4 - T 1:27:04



2.6.2004

Funkce generovat_stavy() od nynějška vrací stavy nalezené novým kódem. K tomu je
potřeba, aby se i závěrečná manipulace se stavem (související s koordinacemi) prováděla
nad novými stavy (a to nad všemi ještě před přidáním hrany, tím se zajistí kompatibilita).
Příslušný kus kódu jsem přesunul do funkce stav::pridat_zavislost(). Pouštím dva
výpočty, jeden ještě vrací stav upravený starým kódem a akorát spoléhá na část
přesunutou do pridat_zavislost(), druhý už navíc vrací stavy nalezené novým kódem.
První je belzebub 263, druhý anette 264.

belzebub 263
G 93717 - B 32313 - P 74,4 - T 1:29:30
anette 264
G 92693 - B 33337 - P 73,5 - T 2:10:46

Zdá se, že anette ztrácí na úspěšnosti! Oba výstupy se liší, anette občas místo
odkazu na rodiče vypíše -1!

Obrovská časová náročnost generování stavů možná souvisí s tím, že se všechny stavy
cachují podle stromů. Vypínám ukládání stavů (zakomentovávám ho).

Vracím kód na úroveň 263, tj. závěrečné manipulace zůstávají přesunuté do modulu
stav, ale vrací se pořád stav získaný starým kódem. V zájmu zpřehlednění kódu vyndávám
z generovat_stavy() zavěšování koncové interpunkce vyrábím jí samostatnou funkci
generovat_pro_koncovou_interpunkci().

sakura 265
G 93717 - B 32313 - P 74,4 - T 1:34:14

Přidávám obdobnou funkci pro generování druhé části koordinace.

euler 266
G 93717 - B 32313 - P 74,4 - T 1:59:20

Přidávám obdobnou funkci pro zavěšování valenčních závislostí.

anette 267
G 93717 - B 32313 - P 74,4 - T 2:08:05

U přidávání závislosti do duplikátu stavu v novém kódu jsem našel kopii kódu, který
jsem před 263 přesouval do modulu stav. Teď už by tato kopie měla být nadbytečná,
proto jsem ji smazal.

euler 268
G 93717 - B 32313 - P 74,4 - T 2:22:52

Do zvláštní funkce jsem přesunul i základní generování nových stavů a hledání vítězného
kandidáta.
-> genstav3.pm

sakura 272
G 93717 - B 32313 - P 74,4 - T 1:33:27

Zrušil jsem funkce gererovat_stavy1(), vybrat_viteze() a generovat_stavy_rozskok().
Patřily k větvi, kterou už teď můžu prohlásit za slepou.

belzebub 273
G 93717 - B 32313 - P 74,4 - T 1:24:41

Z nového kódu jsem odstranil nepoužívanou kopii zpracování koncové interpunkce a
valenčních závislostí.

geri 274
G 93717 - B 32313 - P 74,4 - T 1:53:39

Výběr vítěze mezi novými stavy jsem přesunul přímo do funkce, ve které seznam nových
stavů vzniká. Tam, kde se původně vybíral vítěz, se automaticky předpokládá, že
ho najdeme na nulté pozici.
-> genstav4.pm

anette 275
G 93717 - B 32313 - P 74,4 - T 1:50:31

Do zvláštní funkce jsem přesunul i volání lokálních konfliktů, včetně jejich nové
verze.
-> genstav5.pm

euler 277
G 93717 - B 32313 - P 74,4 - T 2:03:12

Nový pokus vrátit z funkce generovat_stavy() pole stavů dodané novým kódem.
-> genstav6.pm

Chyba, proč to poprvé nešlo, je ovšem možná schovaná v rozebrat.pm v backtrack(),
opravil jsem ji, ale rozebrat.pm jsem nezálohoval.

anette 279
G 93719 - B 32311 - P 74,4 - T 1:46:02 !!! MALÉ ZLEPŠENÍ - JAK TO?

Odstraňuji zdvojené zpracování lokálních konfliktů. Nadále se bude používat pouze
volání vázané na nový kód. Parseru by se mělo trochu ulevit co do časových nároků.

sakura 280
G 93719 - B 32311 - P 74,4 - T 1:40:13 !!! MALÉ ZLEPŠENÍ - JAK TO?

Odstraňuji také alternativní části kódu v hlavní části genstavu a kontrolu, zda
nový kód produkuje totéž co starý. A místní zpracování lokálních konfliktů už nevrací
hash s novým kandidátem. Není to potřeba, protože stejně rovnou upraví pole nových
stavů.
-> genstav7.pm

belzebub 281
G 93719 - B 32311 - P 74,4 - T 1:21:57 !!! MALÉ ZLEPŠENÍ - JAK TO?

Kvůli značné časové náročnosti bude generování všech pokračovacích stavů volitelné
a standardně se bude generovat pouze vítězný stav. Zatím pouze vytvořím příslušný
vypínač a vypnu ho.

sakura 282 Alarm! Nízká úspěšnost!
Rychle ještě zkusíme totéž s vypínačem zapnutým. Začátek vypadá rozumně, ale raději
ho nechám doběhnout do konce.

sakura 283
G 93719 - B 32311 - P 74,4 - T 1:37:31 !!! MALÉ ZLEPŠENÍ - JAK TO?

Chyba snad opravena, pouštím znova s vypnutým vypínačem.

geri 284
G 93717 - B 32313 - P 74,4 - T 36:35



Generování stavů je přebudováno. Ještě však není vyřešeno ukládání vygenerovaných
stavů tak, aby bylo později možné se k některému z nich vrátit. To už by se kvůli
rychlosti mělo určitě dělat jen u vytipovaných stromů, kde na konci není v pořádku
valence.

Naposledy jsem se valencí zabýval 22.4.2004, ale jinak. Pak jsem se zabýval zakázanými
přeskoky sloves. 29.4.2004 jsem už psal přímo o ukládání stavů a myslel jsem si,
že ho mám skoro hotové, ale nebyla to pravda. Až dnes to vypadá, že mám funkční
to, co se mi zdálo funkční už tenkrát. A je to celé přebudované.

Nikde ovšem nemůžu najít zmínku o tom, zda už je naprogramované poznávání, že ve
větě není naplněn nějaký valenční rámec. Mělo by to být udělané, protože, pokud
vím, před časem už jsem měl i statistiku, kolika vět se ten tyjátr týká.

V modulu subkat.pm je funkce najit_nenaplnene_ramce(), která přebírá stav analýzy
(např. kvůli návrhu stromu) a odkaz na valenční slovník a vrátí 1, pokud zjistí,
že ve větě existuje sloveso s nenaplněným rámcem a materiál, kterým by rámec šel
naplnit. Tato funkce se momentálně volá z funkce backtrack() v modulu rozebrat,
ale její výsledek se ignoruje.

Mělo by se udělat následující:
- Jestliže byla funkce zavolána na danou větu poprvé a vrátí 1, zapnout ukládání
  stavů a opakovat analýzu věty až k tomuto bodu. Funkci ani nemusíme hned znova
  volat, stav by měl být úplně stejný, jen vedle bude existovat zásoba záložních
  stavů.
- Obnovit vybraný stav. Ideální by bylo obnovit druhé nejlepší pokračování z místa,
  ve kterém jsem si zazdil cestu k naplněnému valenčnímu rámci, ale nevíme, které
  místo to je - cestu jsme si mohli zazdít i nepřímo. Proto obnovíme stav, ve kterém
  nejméně ztratíme na váze oproti stavu, který byl v dané chvíli vybrán původně.
- Samozřejmě z výběru vynecháme stavy, ke kterým se později stejně dospělo normální
  cestou. Mj. se tak vyhneme opakovanému zkoumání dvojic N-A na různých místech
  věty, když ve skutečnosti se do analýzy pohodlně vešly všechny.
- Musíme tedy v nějakém hashi evidovat všechny lesy, ze kterých už jsme ždímali
  pokračovací stavy. Ze zásoby stavů vyloučíme takové, které vycházejí z již známého
  lesa.
- I tak je nebezpečí, že zásoba stavů nezvladatelně poroste. Musíme tedy počet stavů
  v zásobě shora omezit. Nemám ještě jasno jak moc, možná by stačilo na konstantní
  mocninu počtu slov ve větě, třeba na n^2. Jde nám totiž hlavně o to, aby zásobník
  nerostl exponenciálně. Nejdelší věta v testovacích datech má asi 100 slov, n^2
  by tedy bylo 10000.
- Počet stavů ze zásobníku, které skutečně vyzkoušíme, by měl být ještě nižší, abychom
  se výsledku někdy dočkali. Navrhuji namátkou zkusit 50 návratů z konce, pokud
  se dříve nenajde zaplněný valenční rámec.
  - Tím se také bráním "zacyklení" v případě, že věta ve skutečnosti nemá dost
    materiálu do rámců, ale naše primitivní metoda to nezjistila, např. když je
    ve větě jeden akuzativ, ale 2 slovesa, která by ho chtěla. Ze zacyklení by se
    sice teoreticky vyklouzlo vyzkoušením všech možných stavů, ale jejich počet
    je v praxi nutné považovat za blízký nekonečnu.
- Pokud i po "valenčním backtrackingu" zůstane některý rámec nenaplněn, měli bychom
  se vrátit k výsledku, který jsme navrhovali jako první, protože pozdějšími úpravami
  jsme pravděpodobně pokazili další věci.
  - Lepší však bude otestovat, jak to dopadá v praxi, zda třeba jeden návrat v průměru
    nepřinese nějaký užitek.



4.6.2004

Upravuji rozebrat.pm tak, aby se standardně pracovalo bez ukládání záložních stavů,
ale v momentě, kdy se na konci najde nenaplněný (a naplnitelný) slovesný rámec,
se celý rozbor zopakuje s ukládáním stavů. Zatím se s nimi nic nedělá. Ovšem pozor,
nejspíš se nedělá vůbec nic navíc, protože jsem zapomněl vynulovat výchozí stav,
takže strom je ihned hotový.

G 93717 - B 32313 - P 74,4 - T 22:01 - belzebub 285

Oprava. Už resetuju stav před novou analýzou.

G 93717 - B 32313 - P 74,4 - T 22:31 - belzebub 286



7.6.2004

Opravil jsem funkci subkat::najit_nenaplnene_ramce(), nyní snad vrací to, co má.

G 93719 - B 32311 - P 74,4 - T 1:51:54 - anette 305

Byla tam chyba. Po nalezení první věty s nenaplněným rámcem se už přepočítávaly
všechny.

G 93718 - B 32312 - P 74,4 - T 1:28:15 - anette 307 :-(



10.6.2004

Poprvé proběhla celá analýza se zapnutým vracením se pro valenční doplnění. Neočekával
jsem nijak převratné výsledky, ale zatím se výsledek zcela shoduje s výsledkem
analýzy, při níž byla dotyčná vlastnost vypnuta, což je podezřelé.

G 93718 - B 32312 - P 74,4 - T 1:31:59 - freki 312

Pouštím to celé ještě jednou, ale přidávám statistiku, v kolika větách k návratu
došlo, případně ke kolika návratům došlo a kolikrát to vůbec vedlo k nějaké změně
(zatím zjevně nikdy).

Opraveno několik chyb, teď už, zdá se, backtracking funguje, akorát v něm ještě
chybí restrikce na počet stavů, takže hrozí, že buď "nikdy" neskončí, nebo skončí
chybou pro nedostatek paměti. Pokusný běh na větě 6 nasbíral 42000 stavů, pak jsem
ho utnul, protože byl puštěn interaktivně do more a neměl jsem na něj čas. Chtělo
by to při vybírání návratového stavu posoudit, zda v tomto stavu ještě je šance
zaplnit nějakou nezaplněnou valenci. Jinak ho rovnou označit za zpracovaný.

freki 335 ... Podle očekávání hned první backtracking vyhořel na nedostatku paměti
(nageneroval přes 59000 stavů, zpracoval jich asi 4000 a spotřeboval přes 2 GB).



11.6.2004

Potřebujeme seznam slov, která ve větě představují rezervu pro naplňování rámců.
Jsou to slova, která splňují valenční podmínky toho kterého slovesa, ale také je
ještě žádné sloveso neangažovalo (valenčně; mohou však třeba neprávem viset na
modálním slovesu). Abychom takový seznam získali, musíme upravit funkci, která
zatím pouze zjišťuje, zda lze uspokojit neuspokojené požadavky, ale má na víc.



14.-18.6.2004

Pracuju na modulu subkat.pm, aby dokázal říct, které vazby v navrhované analýze
chybí a které pro jejich naplnění nelze využít. Vytvořil jsem funkci obohatit_pole_deti(),
která mi umožní seřadit děti slovesa podle pravděpodobnosti, že jde o argumenty.
V pátek 18.6.2004 v 18:29 jsem to konečně dopsal, teď přijde ladění.



7.7.2004

Po dovolené pouštím parse.pl. Nezačal se vracet už u věty 6, ale až u věty 17.
Ani tady se ale nezdá, že by to mělo někdy skončit. Oprava: Stav, ve kterém není
volný nějaký nadějný uzel (tj. takový, který by mohl zaplnit valenci), se rovnou
označí za zpracovaný. Výpočet konverguje sice o něco rychleji, doopravdy zpracovaných
je teď asi 16000 uzlů, ale stejně je to neúnosně dlouhé a stejně to nakonec skončí
na nedostatku paměti. Půjdeme tedy ještě o krok dál. Budeme hledat stavy, kde je
nadějný uzel už rovnou připojen ke slovesu, které jeho pomoc potřebuje. Budeme
ignorovat fakt, že některé průchody odepisujeme dříve, než mohlo být připojení
vůbec povoleno. Jestliže u některého nadějného uzlu vyzkoušíme všechna jeho připojení
ke všem hledajícím slovesům a nepomůže to, přestaneme daný uzel považovat za naději.
Potřebujeme vědět, pro které sloveso je který uzel nadějí.

Změna. Nebudeme si komplikovat evidenci tím, pro jaké sloveso je jaký uzel nadějí.
Prostě dovolíme pokračování jen ze stavů těsně po zavěšení některého nadějného
uzlu. První úspěch: věta 17 je první, kterou backtracking prošel úspěšně (tj.
podařilo se mu valence zaplnit)! Bylo nasbíráno 11295 stavů, z toho jen 407 bylo
na konci ve frontě nezpracovaných.

I teď bohužel hrozí krach výpočtu z důvodu nedostatku paměti. Zpracované stavy
by se měly ihned po zpracování (nebo zavržení) vyprazdňovat až na příznak {zpracovano}.
Byla by s tím ale spojena další časová režie a navíc se obávám, zda je to bezpečné,
tj. zda opravdu nikde nesahám na jiné položky zpracovaných stavů.

Zatím se zdá, že výpočet by mohl mít šanci na doběhnutí, i když i tak bude trvat
řádově déle než normální výpočty.

geri 362
Výpočet uměle zastaven na větě, kde nejspíš neexistuje optimální zaplnění rámců.
V okamžiku zastavení měl proces alokováno 2,3 GB paměti, nageneroval 101193 stavů,
z toho 4017 zbývalo zpracovat (avšak počet nezpracovaných stále pomalu rostl).

Kromě vyprazdňování stavů bych asi měl omezit celkový počet generovaných stavů (třeba
na 50000?) a celkový počet návratů (500?). Zatím zavádím vyprazdňování stavů a
omezení počtu návratů na 500.

geri 363 - Nakonec také Segmentation fault.

Omezuji počet návratů na 100.

geri 364



13.7.2004, Kolna

Při psaní disertace narážím na problém vztažných vět a toho, proč se pravidlo
pro ně určené uplatní tak málokrát.

Kolikrát se zkoumá, zda jde o správnou závislost typu "který"? 1160-krát.
Ve všech těchto případech už je skutečně přítomno zájmeno "který", ale ještě
není ověřena shoda. Přes některá zájmena se také zkouší natahovat celá řada
závislostí. Měla by se chytat i zájmena visící přes předložku, ale nemám ověřeno,
že to funguje, během výpočtu jsem nic takového neviděl.

Na konci výpočtu už se překvapivě neobjevuje statistika úspěšnosti tohoto pravidla,
takže nemám podle čeho ověřit, jak to je. V testovacích datech je celkem 801 výskytů
tvarů zájmena "který". 48 z nich visí přes předložku.

Ve 483 případech se skutečně pravidlo chytlo. Z toho 389-krát pravidlo zabralo
správně, úspěšnost je tedy 80,5 %.



16.7.2004

Kapitola o plodnosti uzlů. Přetrénovat a znova pustit parser, jednak jako kontrolu,
že vše žije, jednak při trénování přidat událost ZPL - značková plodnost. Např.
"ZPL N7 2 10" znamená, že byl desetkrát zaznamenán případ, kdy uzel se značkou
N7 měl dvě děti.

geri 367 - 3 448 405 událostí - 76 MB - T 11:08
geri 369 - parse.pl nad 367.stat, je to podezřelé, asi nebude úspěšnost taková,
jaká má být. Také se mi výpočet zdá pomalý. Skončilo to po 767 větách!
G 15500 - B 5391 - P 74,2 - T 6:22
Aha! Zůstal zapnutý filtr, který propustil pouze věty obsahující zájmeno "který"!
Vypínám, pouštím znova.

G 93785 - B 32245 - P 74,4 - T 22:12 - geri 370

Překvapení. Po vypnutí valence1 se úspěšnost nečekaně zlepšila o 67 závislostí
oproti nejlepšímu zaznamenanému stavu před jejím zapnutím. Potvrzuji do CVS (kam
současně přidávám modul plodnost.pm).

Zkouším "typickou plodnost" (TFM). Pravděpodobnost i četnost závislosti se násobí
pravděpodobností, že uzel bude mít další dítě. Tato pravděpodobnost má ovšem pouze
tři hodnoty. 0, pokud kvóta dětí už byla naplněna či překročena. 1, pokud ještě
nebyla dosažena. A 0,5, pokud uzel neupřednostňuje jednoznačně konkrétní počet
dětí (tj. není pravda, že dotyčná m-značka byla vidět alespoň 100×, a z toho alespoň
v 80 % s daným počtem dětí).

G 93039 - P 73,8 % (geri 375)

Zkouším "hlídání kvóty dětí" (QFM). Plodnostní pravděpodobnost nyní nabývá pouze
hodnot 0 a 1. Nula je pro uzly, které jednoznačně preferují určitou kvótu, a té
už dosáhly nebo ji dokonce překročily. Pro všechny ostatní je jednička.

G 93113 - P 73,9 % (geri 377)



17.7.2004

Implementuji úplnou plodnost (FFM). Dvě varianty: 3 a více dětí se buď považuje
za jediný stav, nebo se pro každou značku zohledňují všechny počty dětí, se kterými
byla viděna. Pokud se 3 a více dětí eviduje najednou, dostane uzel, který už má
3 děti, automaticky 0.5. Pozor, opravené počítání pravděpodobnosti oproti Modelu Jedna: když
chce uzel buď 0 nebo 2 děti, ale rozhodně ne 1, a už jedno dostal, má velmi vysokou
pravděpodobnost, že dostane i druhé!

G 93677 - P 74,3 % (geri 378)

Ještě druhá varianta - i velké počty dětí se počítají samostatně.

G 90640 - P 71,9 % (geri 380)



Vzdálenost. Kromě standardního zohledňování sousedství a případného počtu intervenujících
čárek se ještě pravděpodobnost a četnost závislosti dělí vzdáleností obou uzlů.
Činím tak na radu Tomáše Holana, kterému to pomohlo.

G 93845 - P 74,5 % - T 22:34 (geri 381)

Nový rekord! CVS commit.



19.7.2004

Včera jsem zkoumal výskyt neprojektivity (pomocí ../neproj/neproj.pl) ve výstupech
jednotlivých parserů. Zjistil jsem, že u mne se vyskytly všeho všudy dvě (kvůli
modelu n-tic, jinak by nebyly žádné), u Tomových parserů kolem 200 (u jednoho až
1500) a u Zdeňkova přes 2000 (to už odpovídá jejich skutečnému počtu v testovacích
datech).

Současně mě zaskočilo zjištění, že jak Tomáš, tak Zdeněk si nedělají hlavu s tím,
zda jimi zplozená struktura je strom!

Dnes budu přidávat neprojektivity do svého parseru. Začínám sběrem rematizátorů
pro typ RHEM-PREP-cokoli. Kvůli zachování statistického přístupu se chci množinu
rematizátorů naučit z trénovacích dat, nepídím se proto po seznamu, který určitě
mají anotátoři treebanku.

Budu také muset zjistit, zda se některé rematizátory vyskytují v datech v podobné
konstelaci, aniž by byly zavěšeny neprojektivně na uzel za předložkou.

Bohužel se to stává poměrně často. 48 rematizátorů se vyskytlo aspoň jednou jako
rematizátor a aspoň v 50% převažuje jejich zavěšení na uzel za předložkou nad jinými
zavěšeními; obvyklý podíl je však jen mezi 60 a 70%.

Dvě možnosti: 1) natvrdo připojovat rematizátory za předložky. Vzhledem k výše
uvedené statistice by to nemělo mít moc velký úspěch. 2) při zmerčení rematizátoru
pouze udělit výjimku ze zákazu neprojektivních hran. Model rozhodne, zda bude výjimka
využita.

geri 383: pouze povolit, ale nevnucovat
G 94054 - P 74,6 - T 23:19 - Nový rekord!

Chtělo by to zefektivnit a lépe spravovat (volitelné zapínání v konfiguraci), ale
to teď odkládám. Tak, jak to je, přidávám neproj.pm do cvs + commit.

Infinitivy: jestliže infinitiv visí na svém levém sousedovi, všem uzlům, které
mají povoleno zleva viset na tomto sousedovi, povolit také viset na infinitivu.

geri 384
G 94074 - P 74,6 - T 23:17 - Nový rekord!

Li a však: pouze povolíme jejich neprojektivní přeskakování, zbytek ať už si vyřeší
statistika.

geri 392
G 94080 - P 74,6 - T 23:57 - Nový rekord, i když už poměrně zanedbatelný. cvs commit



20.7.2004

Začíná masivní testování za účelem získání závěrečných čísel do disertace.
Vypínám podmíněnou pravděpodobnost, místo ní absolutní četnost závislosti.

geri 394
G 90684 - P 72,0 - T 23:11

Přidávám alternativní verzi funkce zjistit_povol(), která vedle komponentového
budování stromu umožní také budování shora dolů. Pozor, zatím je důsledkem vypnutí
kontroly projektivity, takže výsledek bude asi strašný.
geri 395
Zdá se, že se výpočet zacyklil u věty 14. Parser asi bohužel počítá s tím, že závislosti
jsou povolovány určitým způsobem, a teď nemám čas ho učit něco jiného. Zkusím ještě
funkci obohatit o kontrolu projektivity a když to nepomůže, tak to zabalím. Ne,
balím to hned. Kontrola, že funguje původní nastavení (abscetnost=0, komponentove=1).
geri 400
G 93845 - P 74,5 - T 23:30
Ještě zůstaly vypnuté neprojektivity. Při této příležitosti je trochu umravním
a jejich zapínání přesunu do parser.ini (zatím bylo nutné ho zakomentovat v genstav.pm).
Zruším model neproj.pm (i z CVS) a vše přesunu do povol.pm.
geri 407
G 94080 - P 74,6 - T 25:39 OK.

Redukce značek. Natrénovat model neredukovaných značek. Také se pokusit o redukci
způsobem používaným v Modelu Jedna - někde mám přibližný překlad všech značek.
freki 401 - trénuje s vypnutou redukcí značek
3 970 666 událostí - T 11:40
freki 408 - parse.pl nad 401 (i teď je pochopitelně vypnutá redukce)
G 88351 - P 70,1 - T 26:37

Natrénovat model značek redukovaných baltimorskou metodou.
freki 410 - trénuje s baltimorskou redukcí
3 659 134 událostí - T 11:13
freki 411 - parse.pl nad 410 (zapnuta baltimorská redukce)
G 89535 - P 71,0 - T 26:02

Různá míra lexikalizace (ne té selektivní, ale lambda).
Opět zapnout současnou redukci značek a použít statistiku 374.stat.
geri 412 - parse.pl: ls = 0.734375
G 94080 - P 74,6 - T 25:45
freki 413 - parse.pl: ls = 0
G 93090 - P 73,9 - T 40:21
freki 414 - parse.pl: ls = 1
G 69142 - P 54,9 - T 39:27

Selektivní lexikalizace.
geri 416 - train.pl: vypnutá selektivní lexikalizace
3 061 758 událostí - T 10:34
geri 418 - parse.pl nad 416.stat
G 91038 - P 72,2 - T 24:14

Ještě potřebujeme vypínat selektivní lexikalizaci jednotlivých slovních druhů
zvlášť.
train geri 420 - bez předložek - T 11:40
  parse geri 426
  G 93904 - P 74,5 - T 31:33
train geri 421 - bez podřadících spojek - T 18:47
  parse geri 427
  G 93604 - P 74,3 - T 31:38
train geri 422 - bez zájmen - T 18:32
  parse freki 428
  G 93668 - P 74,3 - T 35:07
train freki 423 - bez vybraných příslovcí - T 17:17
  parse freki 429
  G 93487 - P 74,2 - T 34:42
train geri 432 - bez slovesa být - 3365461 událostí - T 11:01
  parse geri 433
  G 92235 - P 73,2 - T 24:40
train freki 425 - bez pseudovalence (tj. selektivní lexikalizace sloves) - T 17:12
  parse drak 431
  G 93987 - P 74,6 - T 24:05



21.7.2004

Další problém s pseudovalencí je na straně 52. Jsou tam úspěšnosti měřené nejen
dávno, ale hlavně jen na závislostech na slovesech (Sb|Obj|AuxT|Pnom|Adv). Včera
jsem zjistil, že na celkové úspěšnosti se vypnutí pseudovalence na prvním desetinném
místě vůbec neprojeví (byť malý rozdíl v počtu správných závislostí existuje).

S vypnutou pseudovalencí (431.vysledky) to bylo 84,6 %.
Se zapnutou pseudovalencí (412.vysledky) to bylo 84,9 %.

Opět počítám normální úspěšnost na všech uzlech. Vyhodnocení pseudovalence už máme
ověříme ji ale i v kombinaci s valencí0. Valenci0 také vyhodnotíme samostatně.
Valenci1 už kvůli časovým nárokům nebudeme znova testovat a zveřejníme číslo zjištěné
posledním pokusem. Stejně nebylo na celých datech.

Pro pseudoval=0 použít statistiku 425, pro pseudoval=1 použít 374.

pseudoval=0, valence=0 ... už máme (běh 431 včera): G 93987 - P 74,6 - T 24:05 freki
pseudoval=0, valence=1 ... geri 434:                G 91866 - P 72,9 - T 24:51 geri
pseudoval=1, valence=0 ... freki 435:               G 91882 - P 72,9 - T 25:11 freki
pseudoval=1, valence=1 ... drak 436:                G 91882 - P 72,9 - T 24:46 drak
Totožný výsledek na posledních dvou řádcích mi byl podezřelý, několikrát jsem kontroloval
záznam nastavení, ale opravdu to bylo puštěno správně. AŽ NA TO, ŽE BYLO VYPNUTO SELEX BÝT
OPRAVA:
pseudoval=0, valence=1 ... geri  437:               G 93987 - P 74,6 - T 24:21 geri
pseudoval=1, valence=0 ... freki 439:               G 94080 - P 74,6 - T 24:37 freki
pseudoval=1, valence=1 ... drak  438:               G 94080 - P 74,6 - T 25:17 drak
Teď už výsledky nekolidují s dřívějšími zjištěními, ale je podezřelé, že parametr
$konfig{valence} nemá na výsledky žádný vliv. Ukazuje se, že při přestavbě genstav.pm
se úplně vytratila podmínka, která se na tento parametr dívá. Podmínku vracím a
řádky s valence=0 testuju znova, možná se budeme divit.
pseudoval=0, valence=0 ... teď už nemusí odpovídat včerejšímu 431; geri 440: G 93987 P 74,6
pseudoval=1, valence=0 ... freki                                        441: G 94080 P 74,6
Inu, valence zřejmě trvá na svém, že celkový výsledek nijak ovlivňovat nebude.

Žárlivost. Pouštím trénink, který si u OZZ (a u ničeho jiného!) všímá, zda na daném
rodiči visí ještě jiný uzel se stejnou značkou jako posuzované dítě.
train geri 442 - 3449293 událostí - T 11:29
parse geri 444 - G 81075 - P 64,3 - T 24:57

Žárlivost opět vypnuta, pro jistotu pouštím kontrolní běh, který má zjistit, zda
opět dosahujeme maximální známé úspěšnosti G 94080 - P 74,6.
geri 445 - G 94080 - P 74,6 - T 24:21
Potvrzeno.

Zákaz přeskakování sloves (definovaný souborem zakazy_preskoceni.txt). Vypínám ho
příznakem nepreskocv=0. Přetrénování není nutné.
freki 446 - G 93914 - P 74,5 - T 22:27

Plodnost se zatím zapínala a vypínala natvrdo v kódu. Předělávám ji tak, aby se
dala zapnout v konfiguračním souboru a navíc aby se dalo vybrat ze tří přístupů
popsaných v disertaci (FFM, TFM a QFM). Statistika plodnosti není přímou součástí
hlavní statistiky, ale čte se ze zvláštního souboru plodnost.txt. Proto přepínač
umisťuju mezi parametry, jejichž změna nevyžaduje přetrénování.

ffm - geri 447   - G 93852 - P 74,5 - T 25:26
tfm - freki 448  - G 93292 - P 74,0 - T 24:27
qfm - drak 449   - G 93315 - P 74,0 - T 24:22
nic - sakura 450 - G 94080 - P 74,6 - T 31:27

Experimenty se vzdáleností.
1: Vzdálenost v žádné podobě není parametrem pro váhu závislosti.
2: Parametrem je, zda řídící a závislý spolu sousedí (standard Modelu Jedna).
3: Třetí stav - výskyt čárky mezi řídícím a závislým. Nyní je parametrem B/D/,.
4: Jako 3, ale váha závislosti se navíc dělí vzdáleností mezi oběma uzly.
Nejdříve je třeba natrénovat modely pro 1 a 2. Pro 3 už natrénováno máme a 4 trénování nevyžaduje.

1: train geri 451  - 3283615 událostí - T 10:42
   parse geri 456  - G 91200 - P 72,4 - T 24:08
2: train freki 452 - 3418129 událostí - T 10:41
   parse freki 457 - G 91926 - P 72,9 - T 24:32
3: 374.stat
   parse drak 453  - G 94032 - P 74,6 - T 23:38
4: 374.stat
   známý výsledek  - G 94080 - P 74,6

Koordinace. Nejdříve kontrolní běh, že je opět úspěšnost na maximu.
parse geri 458  - G 94080 - P 74,6 - T 24:34
Teď prostě zkusím koordinace=0 v parser.ini. Je tam napsáno, že se musí přetrénovat,
tož přetrénujem.
train freki 459 - 3390516 událostí - T 23:02
parse freki 460 - G 92267 - P 73,2 - T 22:35



22.7.2004

Krátké věty. Zatím se nedají vypínat a zapínat. Zařadím přepínač do sekce nevyžadující
přetrénování, protože při přetrénování se potřebné statistiky sbírají každopádně.
geri 461 - G 93838 - P 74,5

N-tice. Podobně jako krátké věty dosud nebyly volitelné, teď budou.
geri 462 - G 92556 - P 73,4
Chyba, současně zůstaly vypnuté i krátké věty! Znova!
geri 463 - G 93054 - P 73,8

Pevná omezení.

Připojování koncové interpunkce ke kořeni.
freki 464 - G 91339 - 72,5

Závislosti na kořeni nerozlišují směr, ale zato kontrolují přítomnost slovesa ve
větě. Pozor, při změně tohoto přepínače se musí přetrénovat!
train geri 465 - 3445058 událostí
parse geri 466 - G 94027 - P 74,6



23.7.2004

Plodnost kořenu nesmí být větší než 2.
parse geri 468 - G 93725 - P 74,4

Právě jedna vnější závislost do úseku mezi dvěma čárkami.
parse geri 469 - G 93545 - P 74,2

Na čárce nesmí viset nic.
parse geri 470 - G 93923 - P 74,5

Zákaz přeskakování bezdětných předložek.
parse geri 471 - G 94024 - P 74,6

Zákaz přeskakování podstatných jmen v genitivu.
parse geri 472 - G 94112 - P 74,7
Wow! Takže přestože to kdysi pomáhalo, teď je naopak lepší to vypnout!
cvs commit
Předcházející pokusy už přepočítávat nebudu, akorát všude, kde v disertaci mluvím
o závěrečné úspěšnosti, změním 74,6 na 74,7.

Zvláštní zpracování vztažných vět se zájmenem "který".
parse geri 473 - G 93967 - P 74,6
V d-test datech se 801-krát vyskytuje tvar zájmena "který".
1160-krát se parser ptal na některou závislost, která přes "který" měla vést (na některé
se mohl ptát opakovaně a přes některé výskyty "který" mohlo vést několik potenciálních
závislostí, zejména protože před zájmenem leželo několik podstatných jmen. 483-krát
se nakonec pravidlo aplikovalo a závislost byla přijata; z toho 389x správně. To
dává úspěšnost pravidla 80,5 %.

Vypnutí všech vypínatelných vlastností Modelu Dva najednou:
vztaz = 0
nepreskocg = 0 (má být nyní vypnuto i ve finální verzi)
predlozky = 0
carka_je_list = 0
mezicarkove_useky = 0
koren_2_deti = 0
pod_korenem_sloveso_misto_smeru = 0
koncint = 0
----- tady končí pevná omezení
ntice = 0
krvety = 0
koordinace = 0
vzdalenost = 0
vzdalenost_delitel = 0
... plodnost zůstává vypnutá stejně jako ve finální verzi
nepreskocv = 0
selex = 0
pseudoval = 0
upravovat_mzn = 0 (místo 2)
abscetnost = 1 (místo 0)
neselektivní lexikalizace zůstala na lambda = 0.734375

Musíme přetrénovat, pak teprv testy!
train geri 474 - 3459989 událostí - T 9:10
parse geri 475 - G 71160 - P 56,5 - T 13:29 (!)

Teď zase vše zapnout, až na pevná omezení.
I tak se to musí přetrénovat a nemůže se použít 374.stat, protože za pevné omezení
považuju i to, že se při trénování pod kořenem místo směru kouká na přítomnost slovesa.
train geri 477 - 3445058 událostí - T 11:03
parse geri 478 - G 91177 - P 72,3 - T 21:57



Rychle ověřit, že po opětovném zapnutí všech úspěšných vylepšení a přepnutí na 374.stat
se úspěšnost vrátí k rekordní hodnotě.
parse geri 479

dtest data 0.5 (bez přetrénování na 0.5!)
parse geri 484 - G 46505 - B 17213 - P 73,0
etest data 0.5 (bez přetrénování na 0.5!)
parse geri 485 - G 47653 - B 17737 - P 72,9

Přetrénovávám podle trénovacích dat z Baltimoru.
train geri 486 - 1218787 událostí - T 2:45
parse geri 488 dtest - G 45299 - P 71,1
parse geri 487 etest - G 46504 - P 71,1

ETEST 1.0 (s maximálním výkonem a 374.stat)!!!
A 125713 - G 94121 - B 31592 - P 74,9



24.7.2004

Natrénovat na různých zdrojích morfologie. Bohužel se to nebude týkat vedlejších
statistik, jako jsou n-tice, krátké věty či zákazy přeskakování sloves. Nemám už
čas, abych to dotáhl do konce. Pokud se ale potvrdí, že nejlépe to funguje na
statistice z taggeru, nebude žádné dotahování do konce nutné.

human
  train geri 491  - 3397730 událostí - T 10:56
tagger a
  už hotovo (374) - 3448365 událostí
tagger b
  train geri 492  - 5238005 událostí - T 11:27
dictionary
  train freki 493 - 6394663 událostí - T 27:12

Je docela divné, o kolik více událostí se objeví při použití taggeru b oproti taggeru
a. Teď proběhne parsing. Nejdřív každý na svém, "human" vynecháváme, protože bychom
ho museli testovat na jiných datech.

tagger a - tagger a (374.stat)
  už hotovo (472): G 94112 - P 74,7
tagger b - tagger b (492.stat)
  geri 495
dictionary - dictionary (493.stat)
  freki 496

human    - tagger a
human    - tagger b

Parsing nad 493.stat (nezjednoznačněná morfologie) spadl na nedostatku paměti.
Nejdřív ze statistiky vyházím věci, které se už léta trénují jen ze zvědavosti,
konkrétně události typu RAM, OSZ, OZS, ZZZ, ZSZ, ZZS, ZSS. Tím se statistika zmenší,
potom se ale asi stejně bude muset zkoumat, co je při výměně morfologického zdroje
špatně.

MM ad train geri 497.stat - 2875424 událostí (97 MB) - T 20:14
MD a  parse geri 505 - G 91949 - P 73,0

MM ad parse geri
Někde se ztrácí paměť! Po načtení statistiky do parseru má proces jen 400 MB,
ale pak se klidně vyšplhá na 2 GB a spadne!



1.8.2004

Přeprogramoval jsem rozepisování alternativ jiným způsobem a přestala se ztrácet
paměť.

MM ad train i parse - G 85754 - P 68,0 - T 47:22 - geri 524

Problém je, že při trénování se zřejmě alternativy rozepisovaly špatně. Proto upravím
train.pl, aby používal tutéž funkci, a pustím trénink ještě jednou.

train geri 526 - 2872481 událostí (96 MB) - T 33:20
parse geri 527 - G 85460 - P 67,8 - T 47:29

Druhá verze: nejednoznačná morfologie, ale bez rozepisování alternativ (tj. řetězec
značek se považuje za jedinou značku).

train geri 528 - 1774510 událostí (55 MB) - T 9:09
parse geri 529 - G 89553 - P 71,1 - T 21:23

DOSUD ZJIŠTĚNO:
526+527: G 85460 - P 67,8 - T 47:29 - oba MM ad rozepsaně
528+529: G 89553 - P 71,1 - T 21:23 - oba MM ad nerozepsaně
374+472: G 94112 - P 74,7 - T 24:21 - oba MD a

Teď znova natrénujeme podle MD b.

train geri 530 - 2379504 událostí (56 MB) - T 7:41
parse geri 531

Průběžná úspěšnost je opět děsivě nízká, jak to?
Regulární výraz pro <MDt src="b"> chytal úplné nesmysly. Je nutné přetrénovat.

train geri 534 - 1381009 událostí (34 MB) - T 7:30
parse geri 535 - G 93920 - P 74,5 - T 23:46

Nové nastudování MD a:

train geri 536 - 1379879 událostí (33 MB) - T 7:44
parse geri 537 - G 93840 - P 74,5 - T 22:35
GRRR!!!
Jak to, že to není totožné s 374+472?
Zapínám rozepisování alternativ (možná se stopově vyskytlo i u MD?), používám 374.stat.
parse geri 538 - G 93721 - P 74,4 - T 40:47



2.8.2004

Takže znova. Zrušíme současný způsob rozepisování, zapneme ten původní (i když
si myslím, že je chybný). A použijeme 374.stat a MD a.

parse geri 539 - G 93721 - P 74,4 :-(( - T 26:11

Bez ohledu na výsledek pátrání po původním optimu budu vyplňovat ostatní buňky
tabulky. Jejich odchylky od hodnot, které bych dostal, kdybych znal a odstranil
příčinu problému s optimem, by pravděpodobně byly zanedbatelné.

MM ad + MD a, tj. nastavit zdroj na MD a a statistiku na 526.stat. Rozepisování
alternativ opět vypnout kvůli časovým nárokům.

parse freki 541 - G 91866 - P 72,9 - T 26:43

MM ad + MD b, tj. nastavit zdroj na MD b a statistiku na 526.stat. Rozepisování
alternativ vypnout kvůli časovým nárokům.

parse geri 542 - G 91964 - P 73,0 - T 29:42

MD a + MM ad, tj. nastavit zdroj na MM ad, zapnout rozepisování alternativ, přepnout
na statistiku 536.stat.

parse freki 543 - G 87236 - P 69,2 - T 48:52

MD a + MD b, tj. nastavit zdroj na MD b, vypnout rozepisování alternativ, přepnout
na statistiku 536.stat.

parse belzebub 544 - G 93900 - P 74,5 - T 24:45

MD b + MM ad, tj. nastavit zdroj na MM ad, zapnout rozepisování alternativ, přepnout
na statistiku 534.stat.

parse drak 545 - G 87237 - P 69,2 - T 46:50

MD b + MD a, tj. nastavit zdroj na MD a, vypnout rozepisování alternativ, přepnout
na statistiku 534.stat.

parse geri 546 - G 93743 - 74,4 - T 29:04

human: Nejdříve je potřeba natrénovat statistiku.

train loki 547 - 1354520 událostí (33 MB) - T 13:31

human + MM ad, tj. nastavit zdroj na MM ad, zapnout rozepisování alternativ, přepnout
na statistiku 547.stat.

parse geri 548 - G 87239 - P 69,2 - T 46:39

human + MD a, tj. nastavit zdroj na MD a, vypnout rozepisování alternativ, přepnout
na statistiku 547.stat.

parse geri 549 - G 93188 - P 73,9 - T 23:41

human + MD b, tj. nastavit zdroj na MD b, vypnout rozepisování alternativ, přepnout
na statistiku 547.stat.

parse freki 550 - G 93296 - P 74,0 - T 23:12

DOSUD ZJIŠTĚNO:

MM ne + MM ne = 528+529: G 89553 - P 71,1 - T 21:23 (ne znamená nerozepsaně)
MM ad + MM ad = 526+527: G 85460 - P 67,8 - T 47:29
MM ad + MD a  = 526+541: G 91866 - P 72,9 - T 26:43
MM ad + MD b  = 526+542: G 91964 - P 73,0 - T 29:42
MD a  + MM ad = 536+543: G 87236 - P 69,2 - T 48:52
MD a  + MD a  = 374+472: G 94112 - P 74,7 - T 24:21 (mělo by být totéž jako 536+537, ale není, chybu neznám)
MD a  + MD b  = 536+544: G 93900 - P 74,5 - T 24:45
MD b  + MM ad = 534+545: G 87237 - P 69,2 - T 46:50
MD b  + MD a  = 534+546: G 93743 - P 74,4 - T 29:04
MD b  + MD b  = 534+535: G 93920 - P 74,5 - T 23:46
human + MM ad = 547+548: G 87239 - P 69,2 - T 46:39
human + MD a  = 547+549: G 93188 - P 73,9 - T 23:41
human + MD b  = 547+550: G 93296 - P 74,0 - T 23:12



3.8.2004

cvs tag rel-3-4, aby se dala snadno rozbalit dosud nejlepší verze parseru. Současná
verze sice na rozdíl od ní umí lépe rozepisovat alternativy, ale zatím je to za
cenu poklesu úspěšnosti. Na hledání chyby teď nemám čas, musím ho odložit.

Současnou verzi kopíruju do záložní složky a přes ni rozbaluju rel-3-4. Pouštím
pokusný běh, který má ověřit, že jsme se opravdu vrátili k úspěšnosti 74,7 % (G 94112).

parse geri 551 - G 94112 - P 74,7 - T 24:53

Pro jistotu do CVS ukládám i novější verzi (správné rozepisování, nižší úspěšnost).
Ihned ji také taguji, aby se dala samostatně rozbalit.
cvs commit
cvs tag rel-3-4b

cvs commit, aby se uchovala verze, která umí správně rozepisovat alternativy. Pak
se však musím vrátit k optimální verzi co do úspěšnosti, abych mohl pokračovat
v pokusech pro disertaci.

Zjistit úspěšnost na větách, a to jak celkovou, tak na větách jednotlivých délek.
Upravuju parse.pl. Přidávám do něj taky jedinou změnu, kterou měla jeho rel-3-4b
oproti rel-3-4 - v tomto případě by totiž neměla mít opravdu žádný vliv na úspěšnost.

parse geri 552 - G 94112 - P 74,7
7319 vět, z toho 1539 stoprocentních, tj. větná úspěšnost 21,0 %.
126030 slov, z toho 10716 ve stoprocentních větách, tj. vážená větná úspěšnost 32,1 %.
Podle délky vět:
délka - vět - správných - úspěšnost
 1  55  55 100,0
 2 199 198  99,5
 3 151 122  80,8
 4 209 148  70,8
 5 274 196  71,5
 6 220 118  53,6
 7 276 128  46,4
 8 248  93  37,5
 9 267  98  36,7
10 313  85  27,2
11 282  64  22,7
12 289  50  17,3
13 289  48  16,6
14 297  29   9,8
15 280  31  11,1
16 262  16   6,1
17 273  11   4,0
18 275  14   5,1
19 249  10   4,0
20 231   6   2,6
21 218   6   2,8
22 198   4   2,0
23 193   3   1,6
24 183   2   1,1
25 162   2   1,2
30 101   1   1,0
32  70   1   1,4

Ještě zjišťuju aktuální SLOVNÍ úspěšnost na různě dlouhých větách.

parse geri 557

Úspěšnost vážená obtížností (opět celková i na větách určité délky).

parse geri 559
VAZENO OBTIZNOSTI: A 118711 - G 88372.7251405133 - P 0.744435858012427
D   2 - N   99 - A    199 - G    198 - P  99.5
D   3 - N  100 - A    302 - G    275 - P  91.2
D   4 - N  156 - A    627 - G    553 - P  88.3
D   5 - N  219 - A   1096 - G    978 - P  89.3
D   6 - N  183 - A   1100 - G    926 - P  84.2
D   7 - N  236 - A   1656 - G   1381 - P  83.4
D   8 - N  217 - A   1736 - G   1444 - P  83.2
D   9 - N  237 - A   2136 - G   1757 - P  82.3
D  10 - N  281 - A   2817 - G   2276 - P  80.8
D  11 - N  256 - A   2820 - G   2244 - P  79.6
D  12 - N  264 - A   3179 - G   2536 - P  79.8
D  13 - N  266 - A   3468 - G   2772 - P  79.9
D  14 - N  275 - A   3861 - G   2993 - P  77.5
D  15 - N  261 - A   3920 - G   3056 - P  78.0
D  16 - N  245 - A   3930 - G   2955 - P  75.2
D  17 - N  256 - A   4368 - G   3314 - P  75.9
D  18 - N  259 - A   4675 - G   3573 - P  76.4
D  19 - N  235 - A   4482 - G   3378 - P  75.4
D  20 - N  219 - A   4389 - G   3286 - P  74.9
D  21 - N  207 - A   4360 - G   3277 - P  75.2
D  22 - N  189 - A   4158 - G   3000 - P  72.2
D  23 - N  184 - A   4246 - G   3149 - P  74.2
D  24 - N  175 - A   4209 - G   3146 - P  74.7
D  25 - N  155 - A   3888 - G   2872 - P  73.9
D  26 - N  147 - A   3825 - G   2769 - P  72.4
D  27 - N  149 - A   4030 - G   2880 - P  71.5
D  28 - N  117 - A   3294 - G   2464 - P  74.8
D  29 - N  115 - A   3360 - G   2448 - P  72.9
D  30 - N   97 - A   2929 - G   2100 - P  71.7
D  31 - N   69 - A   2160 - G   1536 - P  71.1
D  32 - N   67 - A   2170 - G   1546 - P  71.2
D  33 - N   70 - A   2336 - G   1699 - P  72.8
D  34 - N   57 - A   1947 - G   1345 - P  69.1
D  35 - N   49 - A   1734 - G   1195 - P  69.0
D  36 - N   43 - A   1575 - G   1085 - P  68.9
D  37 - N   37 - A   1404 - G    962 - P  68.5
D  38 - N   34 - A   1295 - G    913 - P  70.5
D  39 - N   38 - A   1482 - G   1045 - P  70.5
D  40 - N   36 - A   1443 - G    991 - P  68.7
D  41 - N   24 - A   1000 - G    713 - P  71.3
D  42 - N   23 - A    984 - G    647 - P  65.8
D  43 - N   24 - A   1050 - G    726 - P  69.2
D  44 - N   17 - A    774 - G    522 - P  67.6
D  45 - N   19 - A    880 - G    606 - P  68.9
D  46 - N   15 - A    720 - G    483 - P  67.1
D  47 - N   12 - A    598 - G    422 - P  70.7
D  48 - N   16 - A    799 - G    558 - P  69.9
D  49 - N   12 - A    624 - G    429 - P  68.8
D  50 - N   13 - A    686 - G    457 - P  66.7
D  51 - N    9 - A    500 - G    332 - P  66.5
D  52 - N    5 - A    306 - G    206 - P  67.6
D  53 - N    8 - A    468 - G    301 - P  64.4
D  54 - N    4 - A    265 - G    184 - P  69.6
D  55 - N    2 - A    162 - G    118 - P  73.3
D  56 - N    5 - A    330 - G    231 - P  70.2
D  57 - N    4 - A    280 - G    125 - P  44.9
D  58 - N    2 - A    171 - G     89 - P  52.3
D  59 - N    0 - A     58 - G     35 - P  61.0
D  60 - N    3 - A    236 - G    157 - P  66.7
D  61 - N    1 - A    120 - G     67 - P  56.6
D  62 - N    0 - A     61 - G     30 - P  50.0
D  63 - N    2 - A    186 - G    101 - P  54.5
D  64 - N    1 - A    126 - G     84 - P  67.2
D  65 - N    0 - A     64 - G     29 - P  46.2
D  66 - N    0 - A     65 - G     40 - P  62.1
D  68 - N    1 - A    134 - G     76 - P  57.4
D  70 - N    0 - A     69 - G     45 - P  65.7
D  72 - N    0 - A     71 - G     41 - P  58.3
D  73 - N    0 - A     72 - G     39 - P  54.8
D  74 - N    0 - A     73 - G     51 - P  70.3
D  75 - N    0 - A     74 - G     30 - P  41.3
D 100 - N    0 - A     99 - G     49 - P  50.0
Výpočet skončil v 17:03:52.
Program běľel 00:24:22 hodin.



4.8.2004

Zjišťuju, jaká bude úspěšnost, když vynechám závislosti, které byly vidět méně
než pětkrát (tzv. experiment 1 v disertaci). A jaká bude přesnost a úplnost.

parse geri 562

Navíc přidávám jako alternativní závislosti, které dosahují alespoň 90% váhy vítězné
závislosti. Protože to vyžaduje generovat všechny stavy a bude to trvat mnohem déle,
pouštím to ihned. Ještě bych měl vymyslet, jak se zjistí P+R obou pokusů najednou.
Z časových důvodů se na to ale asi vykašlu úplně.

parse geri 563 - AA 126030 - A 133500 - G 95622 - P 71,6 - R 75,9 - F 73,7

Pouštím test, který dodá úspěšnost rozdělenou podle vzorových s-značek (afunů).

parse freki 564; výsledky viz disertace, část 13.5.

Chystám trénink na menších datech.

1000 vět: train geri 566
  parse freki 570 - A 126030 - G 84202 - B 41828 - P 0.668110767277632 - T 33:13
10000:    train freki 567
  parse freki 571 - A 126030 - G 90130 - B 35900 - P 0.715147187177656 - T 33:05
25000:    train freki 568
  parse geri 572  - A 126030 - G 92499 - B 33531 - P 0.733944298976434 - T 38:08
50000:    train geri 569
  parse geri 573  - A 126030 - G 93623 - B 32407 - P 0.742862810441958 - T 38:35



Nyní parsing na uměle zmenšeném modelu (tj. použijeme 374.stat, ale vyházíme z něj
všechny události viděné N-krát).

N<1:  3351830 ud, 574.stat, 73 MB, parse freki 579 - G 94112 - P 74,7 - T 24:42
N<=1:  944195 ud, 575.stat, 20 MB, parse freki 580 - G 93802 - P 74,4 - T 24:19
N<=2:  538557 ud, 576.stat, 11 MB, parse geri 581  - G 93638 - P 74,3 - T 24:27
N<=5:  238984 ud, 577.stat,  5 MB, parse geri 582  - G 93159 - P 73,9 - T 24:14
N<=10: 123386 ud, 578.stat,  2 MB, parse drak 583  - G 92595 - P 73,5 - T 23:19

Trénuju výhradně na Lidových novinách. 865 souborů.
train geri 584, 698671 slov, přes 39900 vět, NEVYPSALA SE ŽÁDNÁ STATISTIKA!
train geri 600, 865 souborů, 39978 vět, 698671 slov, 2187990 událostí, 48 MB, T 6:00
parse geri 601 - G 93534 - P 74.2 - T 24:30

Pro srovnání potřebujeme trénovací sadu, ve které bude stejný nebo téměř stejný
počet vět, ale ze všech zdrojů, pokud možno ve stejném poměru, v jakém se podílejí
na celých trénovacích datech. Celkem máme 73088 vět, chceme vybrat 39978 vět.
Vezmeme tedy každý (73088/39978)-tý, tj. každý 1,83-tý soubor.

train freki 602, 864 souborů, 39687 vět, 679665 slov, 2171319 událostí, 48 MB, T 5:55
parse geri 603 - G 93392 - P 74,1 - T 24:43

Zjistit, jak se od sebe liší úspěšnost jednotlivých bloků testovacích dat o 100
větách. Pouštím zase klasický parsing se 374.stat, akorát na konci se vypíše zvlášť
úspěšnost bloků.

parse geri 605

Výsledky:
minimum 67,7 %
maximum 82,2 %
Průběžný stav 77 % po 1000 testovacích větách!
Při správném seřazení se dá najít 12 bloků, jejichž celková úspěšnost je 80,1 %.
Obdobně nejhorších 12 bloků má dohromady 69,8 %.

Tak ještě poslední sada testů. Trénuju s vynecháním vět obsahujících ExD.
train geri 610 - 53594 vět - 974838 slov - ALE KURVA NENÍ TAM POSLEDNÍ VĚTA!!! - T 8:17
train geri 613 - 53595 vět - 974841 slov - 2837809 událostí - 63 MB - T 12:41
parse geri 621 - A 99094 - G 75418 - P 76.1 - T 18:07

Trénuju s vynecháním vět obsahujících Coord nebo Apos.
train freki 612 - T 5:56
train geri 614 - 36261 vět - 422292 slov - 1507160 událostí - 32 MB - T 9:29
parse geri 618 - A 41598 - G 34456 - P 82,8

Trénuju s vynecháním vět obsahujících ExD, Coord nebo Apos.
train freki 611 - T 5:43
train freki 615 - 25970 vět - 354784 slov - 1323832 událostí - 28 MB - T 5:29
parse freki 622 - A 36116 - G 29959 - P 83,0 - T 6:07



6.8.2004

Potřebuju nové srovnání 7 parserů, kde bude za můj parser použita jeho nejnovější
verze (G 94112 P 74,7). Např. 552.csts.

We cannot use standard test data because we need held-out data to learn which parser specializes in what. PDT 1.0 d-test data contain 153 files. We keep the first 76 files for testing. The remaining 77 files will be used as held-out data. lv28.csts is the 76th file. The first sentence of lv29.csts is labeled ln94207:76-p3s14 but there are no labels in vse1.csts. The sentence begins with: Celník mi řekl: Ať vám ty květiny nikdy nezvadnou a opice ať se u vás furt usmívá Here begins vseb.csts (held-out data). The first part is vsea.csts (new test data).
New tests: vsea.csts contains 62677 words
ec on vsea.csts: G 53275 - P 85.0 %
mc on vsea.csts: G 52233 - P 83.3 %
zž on vsea.csts: G 47729 - P 76.2 %
dz on vsea.csts: G 47335 - P 75.5 %
th(r2l) on vsea.csts: G 45331 - P 72.3 %
th(l2r) on vsea.csts: G 44063 - P 70.3 %
th(pshrt) on vsea.csts: G 39806 - P 63.5 %
all parsers: G 27817 - P 44.4 %
at least one parser: G 60255 - P 96.1 %
absolute majority or ec: G 53761 - P 85.8 %
absolute majority P+R: G 49277 - left-out 8352 - P 90.7 - R 78.6 - F 84.2
tips: - for all parsers number of times they contribute whenever ec is wrong; - voting where ec has 3 votes, mc 2 votes, others 1 vote each.
Now the same for three parsers (ec, mc, dz).
All parsers: G 42090 - P 67.2 %
At least one parser: G 58126 - P 92.7 %
Absolute majority P+R: G 52627 - O 3890 - P 89.5 - R 84.0 - F 86.7 J
Absolute majority or ec: G 54044 - P 86.2 %

A teď vezmeme vseb.csts a zjistíme trojice mzn-záv/mzn-říď-ec/mzn-říď-mc+dz, při
nichž má pravdu častěji mc+dz než ec (>50%).

A 62669 (JAK TO?) - G 53821 - P 85,9

Další možnosti:
1. Požadovat vyšší úspěšnost jednotlivých trojic (75%, 90%...)
2. Zkusit jen dvojice mzn-záv/mzn-říď-ec.
3. Zkusit jen dvojice mzn-záv/mzn-říď-mc+dz.
4. Zkusit znova trojice i dvojice, ale jen slovní druhy bez pádů.
5. Naopak zkusit kompletní úpravu značek, nejen tu zjednodušenou popsanou výše.

Na celých upravených značkách, mc+dz proti ec.
A 62677 - G 53561 - P 85,5

Zvýšen požadavek na alespoň 2 výskyty, přes 50%.
A 62677 - G 53458 - P 85,3

Zvýšen požadavek na alespoň 2 výskyty, přes 75% (90% ani nemá smysl, to se skoro nevyskytuje).
A 62677 - G 53392 - P 85,2
Výtah z předních míst seznamu:
N1#Z,        9       9  1.000000
PseJ^Vp      8       8  1.000000
NY2N2N2      6       6  1.000000
A6Rv-1N6         6       6  1.000000
...
N6Rs-1Rv-1       6       7  0.857143
VBZ,Jľe      6       7  0.857143
N4VBVf       6       7  0.857143
N1J^Vp      32      39  0.820513
A1VpN1       8      10  0.800000
N6VBRv-1         4       5  0.800000
A4J^N4      11      14  0.785714

Opět uvolněno na aspoň 1 výskyt, přes 50 %. Místo trojic se uvažují dvojice (řídící od Charniaka).
A 62677 - G 53768 - P 85,8

Místo trojic dvojice jako u předcházejícího pokusu, ale místo od Charniaka se řídící bere od MC+DZ.
A 62677 - G 53853 - P 85,9 !!!

Místo úplných upravených značek brát jen slovní druh a pád.
A 62677 - G 53963 - P 86,1 !!!

Totéž, ale nyní nesoutěží MC+DZ proti EC, nýbrž DZ proti EC i MC (ti se nemusejí shodovat).
A 62677 - G 53271 - P 85,0 (dokonce o 4 závislosti horší než EC sám)

Totéž, ale nyní se EC musí shodovat s MC.
A 62677 - G 53268 - P 85,0 (ještě o další 3 závislosti horší)

Vrátit se k tomu, že soutěží MC+DZ proti EC. Zkusit ještě samotné slovní druhy bez
pádů.
A 62677 - G 53999 - P 86,2 !!! to už se konečně blíží k tomu, co dokázalo bezkontextové hlasování :-(

Bezkontextové hlasování (MC+DZ může přehlasovat EC vždycky, EC má přednost pouze
když má každý parser vlastní názor).
A 62677 - G 54044 - P 86,2 !!!

Ještě zkusíme popis souboje obrátit, ale mělo by to snad být totéž co předtím.
Tedy: učíme se, kdy může EC zvítězit, i když je ve sporu s MC a DZ, kteří se shodují.
Rodiče zjišťujeme podle názoru EC. Řídící značka je úplně upravená, závislá jen
slovní druh.
A 62677 - G 54058 - P 86,2 !!!

Totéž, ale obě značky jsou jen slovní druh.
A 62677 - G 54078 - P 86,3 !!!

Totéž, ale obě značky jsou úplně upravené.
A 62677 - G 54090 - P 86,3 !!!



Ještě by stálo za to vědět, kdy má vyhrat Collins místo Charniaka, když všichni
3 máme svůj vlastní názor. Ale teď už to nestíhám vyzkoušet.
tips: - for all parsers number of times they contribute whenever ec is wrong;
 - voting where ec has 3 votes, mc 2 votes, others 1 vote each.
Use weights produced by some parsers (dz, th). Look at zž if it used the "last rule" for that constituent.
Ze sekce 13.5 jasně vyplývá, že neumím koordinace a apozice. Schválně, jestli mi model někdy dovolí přehlasovat Charniaka v závislosti čehokoli na J^ nebo Z,.

Rozšířit zkoumání kontextu tak, že pro libovolnou kombinaci názorů a značek budeme
schopni říct, v kolika procentech se stalo, že některá skupina parserů měla pravdu.
Stihnout to ještě přidat do konečné verze disertace!



Udělat cvs commit kvůli přidanému vyhodnoceni.pm! Nebude to taková sranda, ono
se to totiž brání, že prý současná verze není up-to-date!



Urgentně po dopsání disertace: Uložit do CVS novější verzi parseru (zejména
train.pl a model.pm), která umí správně rozepisovat varianty. Vyvolat z CVS
starší verzi, která uměla dosáhnout maxima 74,7 % na MDa+MDa. Odladit, najít
chybu a sloučit obě verze.



###############################################################################
Nápady:
- Do zpracování neprojektivit přidat neprojektivity koncové interpunkce
  v uzávorkovaných větách.
- jiný přístup k zákazu přeskoků: při trénování si u každé závislosti pamatovat,
  zda přeskočila sloveso
- 25.5.2004: train.pl: Ve funkci spocitat_lokalni_konflikty() se používá pole
  @rodic, které ale při tréninku vůbec neexistuje! Asi je to omyl, je tam totiž
  větev if a else, v jedné z nich je použit @rodic a ve druhé $anot->[]{rodic_vzor}.
  Bohužel to nemůžu teď hned opravit a podívat se, co to udělá s úspěšností, protože
  momentálně krok za krokem upravuju train.pl, aby mohl používat nové knihovny
  a přitom produkoval pořád TUTÉŽ statistiku.
- 14.5.2004: genstav.pm: Dokončování koordinací by se mělo řídit systémem zákazů.
- 26.3.2004: DTEST: 16329 sloves v 7319 větách, tedy 2,23 slovesa na
  větu (včetně tvarů pomocného slovesa být).
  OSNOVA KAPITOLY O SUBKATEGORIZACI
  - Vysvětlit subkategorizaci.
  - Vysvětlit, proč může pomoci při parsingu.
    - SLÍBIL JSEM, ŽE V KAPITOLE 9 UKÁŽU, JAK ZÍSKAT SEZNAM.
  - Tabulka typických argumentů (> 50 % výskytů)
    POZOR, ASI ÚPLNĚ IGNORUJU VÝSKYTY, KDY DANÝ ČLEN VISÍ NA NĚČEM
    JINÉM NEŽ NA SLOVESE.
  - Žárlivá slova, tabulky.
    CHTĚLO BY TO PLYNULEJŠÍ PŘECHOD K ŽÁRLIVOSTI. VYSVĚTLIT, PROČ SE
    TÍM ZABÝVÁM.
  - Odhalení, že je vlastně dost málo chyb, s jejichž odstraněním to
    může pomoci, by mělo přijít až na konec, spíš jako výsledek
    pátrání, proč subkategorizace nenese velké ovoce. Aby bylo do té
    doby o čem psát.
  ---
  - Jak často slovesu něco chybí? 8583 (6,8 %).
  - Jak často slovesu něco přebývá?
  - Jak často jsou na slovese zavěšeny vzájemně nekompatibilní věci?
  ---
  Vf ... infinitiv
  VB ... přítomný čas
  Vp ... příčestí minulé
  Vs ... příčestí trpné
  Nejčastější případ: N4 má viset na Vf, ale bylo zavěšeno na VB.
  P = měli viset a pověsil jsem / pověsil jsem
  R = měli viset a pověsil jsem / měli viset
  29829 věcí mělo viset pod slovesem a zároveň jsem je pod to
  správné sloveso i pověsil. 38412 mělo být. 45255 bylo.
  P = 29829 / 45255 = 65,9 %
  R = 29829 / 38412 = 77,7 %
  F = 2PR/(P+R) = 71,3 %
- 8.4.2004: Koordinace: Každé "a" musí mít pod sebou koordinaci!
  Pokud těsně za "a" leží sloveso, musí to být koordinace sloves!
- 8.4.2004: 592 případů (0,47 %), kdy visí Z: na VB, když mělo viset
  na J^. 535 případů, kdy ve stejné situaci figurovalo Vp místo VB.
- 8.4.2004: Do závěru disertace: Named entities by pomohly.
- 8.4.2004: KOPR: Jak se pozná typická závislost, kterou nějaký
  parser umí lépe než jiné parsery?
- 8.4.2004: Tomovy rady:
  - selektivní lexikalizace všech nejčastějších slov bez ohledu na
    slovní druh
  - váha vzdálenosti řídícího a závislého uzlu až do vzdálenosti 15
    (ale je to váha, kterou se přenásobí celá pravděpodobnost,
    neuchovávají se tedy samostatné četnosti událostí o jednotlivých
    vzdálenostech)
- 8.4.2004: Vážené výskyty u sloves. Zatím jsme počítali slovesa, se
  kterými bylo dané doplnění vidět. Teď budeme také počítat,
  kolikrát bylo doplnění se kterým slovesem vidět.
  nd = počet výskytů doplnění
  ns = počet sloves celkem
  š = nd / ns
  Já si do počtu sloves nezapamatuji toto sloveso 1×, ale...???
  Normalizovat na nejčastější sloveso?
  To taky nejde, některá slovesa jsou extrémně častá!
  š je něco jako šance doplnění trefit co nejvíc sloves.
  Problém: š není pravděpodobnost. Může nabývat neomezeně vysokých
  hodnot. Jenže jen málo doplnění se vyskytlo víckrát, než jaký je
  počet sloves:
  N3 6943
  VINF 15263
  N7 10770
  J 10613
  PR4(se) 17253
  R6(v) 16186
  S 22934
  Z 31708
  N4 39375
  DB 38834
  N1 77233
  š(N4) = 7,1. Interpretace: Kolikrát se mohlo vyskytnout s každým
  slovesem? Tím vydělit jeho výskyty - normalizace na četnost - ale
  ne, to bychom dostali vždy počet sloves!
- 8.4.2004: Pro každé heslo a každou vazbu si pamatovat poměr:
  (kolikrát pod sebou má tuto vazbu) / (kolikrát se heslo vyskytlo)
  Pokud se heslo vyskytlo alespoň 5×, zapamatovat si vazbu. Pokud
  pak taková vazba ve větě je a dostane ji jiné heslo, které po ní
  netouží stejně silně, pokusit se přehodnotit.
- 8.4.2004: Která valenční doplnění mají nejhorší úspěšnost?
- 8.4.2004: Pokud existuje něco jako typická chyba, je to závislost
  na koordinacích.
- 8.4.2004: Roztřídit chyby do skupin podle:
  - valenční značky závislého uzlu
  - lemmatu chybně navrženého řídícího uzlu
  - lemmatu správného řídícího uzlu
- Zkontrolovat, zda mám nejlepší a nejnovější seznam valencí.
- Valence předem: pouze přidat do značek heslo tam, kde jde o sloveso.
- Valence EX POST: budovat zásobník stromů a na konci stromy seřadit
  podle míry, do jaké uspokojují valenční požadavky svých uzlů.
- Vylepšení předložek: do značek strkat heslo, ne tvar!
- Neodvozená příslovce zkopírovat do značek.
- Podmínit lambdy konkrétními slovy (např. u slova být potřebujeme vědět, že
  šlo o slovo být, i kdyby o druhém členu závislosti měly rozhodovat jen
  značky).
- Možná konkrétně u slova být by stálo za to přidat slovní tvar do značky.
- Děti - na konci projít zásobník a přehodnotit stromy podle toho,
  kolik dětí má který uzel.
- Podmíněné pravděpodobnosti: nejdříve vybrat řídící uzel (např. podle
  vzdálenosti od optimálního počtu dětí), potom vybírat mezi jeho
  kandidáty na závislý uzel, pravděpodobnosti jsou podmíněné.
- Ještě vylepšit koordinace. A nezapomínat na apozice.
- Valence: Je-li naplněn podmět, už nepřipojovat další. Obdobně u kořene
  naplněno sloveso, u předložky jmenná fráze.
- Valence: negativní pravděpodobnosti: všem závislostem, které nevedou
  k uspokojení nějakého valenčního požadavku, adekvátně snížit pravděpodobnost.
- Valence: Nelze přeskočit neuspokojeného zájemce.
- Při stejné pravděpodobnosti dvou závislostí dát přednost závislosti
  mezi slovy, která k sobě mají ve větě blíž.
- Další způsob, jak čelit Honzovým chybám v pádech: použít morfologickou
  analýzu (popř. s preferencí pádu, který vybral Honza). Poznámka: Občas nejde
  jen o pády, například infinitiv "pomoci" mylně označený jako podstatné jméno
  dokáže taky pořádně nabourat syntaxi.
- Vypočítané lambdy (zkombinovat tolik rozměrů, kolik to utáhne).
- Další otázka kromě plodnosti: je už valenční místo zaplněno? Pokud
  ano, pravděpodobnost je blízká nule.
- Obtížnější úkol: rozpoznat okamžik, kdy se posledního kandidáta na
  zaplnění valenčního místa chystám pověsit jinam.
- Rozlišovat taggery A a B.
- Dovolit si některé závislosti nerozhodnout.
- Dovolit si někde dát na výběr s vahami.
- Vylepšit plodnost. Např. čárka má buď 0, nebo 2, ale nikdy 1. Když
  už dvojka převáží nulu, je nutné to dotáhnout do konce a neskejsnout
  na jedničce.
- Nesnesitelně magnetické souřadící spojky. Přitom:
    - Spojka musí spojovat věci stejného druhu.
    - Věci, které nejsou z různých stran spojky, musí být odděleny
    čárkou.
    - Alespoň 2 věci jsou většinou spojeny, ale není to absolutně
    platné pravidlo, spojky jako "však" se někdy spokojí s jediným
    členem.

- Distinguish the a tagger from the b tagger. Try the morphological analysis weighed using the taggers (both).
- Pomocí analýzy, co bylo kdy kam zavěšeno, zjistit, jaktože lokální konflikty v souhrnu pomáhají, ačkoli jejich vlastní
  vyhodnocení říká, že to, co mají dělat, dělají blbě?

###############################################################################
Úkoly od Honzy:
1. Něco udělat s neprojektivitami (a zjistit, co s nimi dělal Mike).
2. Případně okolo parsingu: převést neprojektivity na projektivity a
zpět (=> článek?).
3. Eugene Charniak: ME inspired parser - prozkoumat, jak to funguje.
###############################################################################
Moje vlastní úkoly:
- Přečíst následující články:
  M. Volk, G. Schneider: Comparing a Statistical and a Rule-Based
  Tagger for German (http://xxx.lanl.gov:80/ps/cs/9811002).
  Anoop Sarkar: Incremental Parser Generation for Tree Adjoining
  Grammar. Proceedings of 34th ACL, Student Session, Santa Cruz, 1996.



-------------
Zajímavé věty
-------------
"Kolik máš vlastně peněz, Michaeli?" ptá se snědý novinář s brýlemi
nejslavnějšího zpěváka planety.