====== Hindi Parsing Shared Task at COLING 2012 Mumbaī ====== http://ltrc.iiit.ac.in/mtpil2012/ ===== Udělat ===== * Natrénovat McDonaldův MST parser. Pokud možno s pořádnými rysy, neprojektivně a druhý řád. Ale na druhou stranu, aby to taky někdy doběhlo. * Zkusit jinou kombinaci rysů ze sloupce FEAT. A zkusit ponechat všechny rysy (žádná redukce). * Natrénovat Malt parser a mezi rysy mu přidat hypotézu od MST (parser MST-Malt podle Joakimova a Ryanova článku). * To znamená, že musím vybrat nejlepší parametry trénování MST, rozdělit trénovací data na 10 dílů, opakovaně natrénovat MST na devíti dílech a pustit ho na ten desátý. Pak musím rozhodnout, jakým způsobem se názor MST předloží Maltu. Musí to být rys položky na vstupu nebo na zásobníku. Asi nejjednodušší by bylo zavést rys, který pro každé slovo řekne značku jeho rodiče. V mnoha větách to bude ukazovat na více než jedno slovo, ale někde to snad pomůže. A pokud místo značky dáme slovo, mohla by být příliš řídká data. (Můžeme ale zavést dva rysy a dát tam obojí.) Index rodiče je jako rys k ničemu, protože hodnota má v každé větě jiný význam. Nejlepší by zřejmě bylo, kdybychom dokázali posuzovat dvě položky najednou (např. dvě horní položky v zásobníku) a říct, zda si MST parser myslí, že mezi nimi vede hrana. Ale to zase neumím popsat a je otázka, jestli to vůbec umí Malt parser, resp. ten jeho SVM rádce. * Zkontrolovat normalizaci UTF-8 (dévanágarí). * Natrénovat samostatný značkovač syntaktických značek. Ambati et al.: MST labeler je blbej, použili maxent (http...lzhang, viz článek). A říkají tam, které rysy a uzly stromu od parseru zkoumali. * Potřebuju nějaké vyhledávadlo a zvýrazňovadlo chyb. * Opravit normalizaci pro HamleDT. Normalizace hindštiny prý dělá na nových datech mnohem více chyb (uzel pod Coord nemá is_member apod.) Mohly by mi pomoct Martinovy transformace koordinací? HTB verze 0,51: train 12041 sent, 268093 tok? (words), dev 1233 / 26416 **MST parser:** V TectoMT share mají verzi 0.4.3b z října 2009 (''$TMT_ROOT/share/installed_tools/parser/mst/0.4.3b''). Já možná mám nebo jsem měl v ''~/nastroje/parsery'' totéž, ale soubor README se tváří, že by to měla být verze 0.5.0. Na [[http://sourceforge.net/projects/mstparser/|Sourceforge]] se tváří, že poslední aktualizace byla 23.1.2012 a verze se stále jmenuje 0.5.0. Resp. možná se tak jmenuje až tahle letošní, protože předcházející aktivita byla 6.5.2011, a to byla zveřejněna verze 0.4.3c. (A verze 0.4.3b ve skutečnosti podle Sourceforge pochází už z 4.4.2007.) Vyhodnotit samostatně * LAS vs. UAS * uvnitř chunku vs. mezi chunky * pro jednotlivé s-značky ===== Výsledky ===== ==== Různé redukce značek ==== Je vhodné využívat formát dat CoNLL, který je i pro MST parser nyní výchozí. Při konverzi do původního formátu MST je nutné rozhodnout, co prohlásíme za morfologickou značku. Pokud nechceme zbytek informace zahodit, tak máme značky velmi dlouhé a neumožňujeme parseru vybrat si, jaká jejich část ho zajímá nejvíc. Naproti tomu ve formátu CoNLL bere MST parser 0.4.3b v úvahu všechny morfologické sloupce (CPOS, POS i FEAT), jak vyplývá z následujících pokusů. Zatím jsem nezkoumal, zda je schopen rozložit obsah sloupce FEAT na samostatné rysy. A nikdy jsem mu nedal kompletní rysy, vždy jsem je omezil buď na vibhakti + tam, nebo jsem je úplně vymazal. Zlatý standard morfologie, trénování na 1000 větách, neprojektivní MST parser 2. řádu. Střídavě jsem redukoval nebo mazal (nahrazoval podtržítkem) hodnoty v různých sloupcích. Parser na všechny tyto změny reagoval a pokaždé dosáhl jiné úspěšnosti. To znamená, že všechny tyto sloupce bere při trénování v úvahu. ^ CPOS ^ POS ^ FEAT ^ UAS ^ LA ^ LAS ^ Model ^ Rysů ^ Čas učení ^ | ano | ano | vibhakti + tam | 91.78 | 79.76 | 77.73 | 131 MB 9.12.2012 23:31:04 | 2 334 346 | 11 min | | ano | ano | ne | 88.47 | 77.52 | 75.55 | 56 MB 9.12.2012 23:32:15 | 1 130 847 | 12 min | | ano | ne | vibhakti + tam | 90.47 | 68.65 | 66.64 | 128 MB 10.12.2012 9:10:05 | 2 246 768 | 11 min | | ne | ano | vibhakti + tam | 88.11 | 77.83 | 74.62 | 127 MB 10.12.2012 9:13:08 | 2 234 096 | 14 min | ==== training-k ==== Ambati et al. použili 2. řád a training-k:5. Zkoušel jsem porovnat training-k:5 a výchozí nastavení (neřeknu nic, čili podle souboru README platí training-k:1). Výstup na dtestu se nelišil ani v jediné závislosti. Parametr training-k jsem ovšem předával pouze při učení, předpokládám, že při použití modelu to nemá smysl. Možná by to chtělo ještě prozkoumat trochu pečlivěji, než to úplně vyhodím. ====== ICON 2009 NLP Tools Contest ====== Soutěž v závislostní syntaktické analýze hindštiny, bengálštiny a telugštiny. Něco jako CoNLL-X a 2007 shared task, ale pro indické jazyky. Tentokrát nezkouším jen DZ Parser, ale hlasující kombinaci tří parserů: Malt parseru, MST parseru a DZ parseru. ===== Zbývá udělat ===== * Upravit makefile tak, abych mohl pouštět pokusy současně se starými i novými daty. A aby se váhy hlasování automaticky upravovaly podle aktuální úspěšnosti dílčích parserů. * Upravit makefile a/nebo skripty pro pouštění Malt parseru tak, aby Malt pro každý jazyk zvolil nejvhodnější algoritmus. * Více si pohrát s rysy. Naučit se parserům předhazovat rysy. U Malt parseru je to dobře zdokumentováno, u MST ne. * Přidat jako rys chunk label, a to i pro DZ Parser. * Naivní parser pro telugštinu: poslední uzel visí na kořeni, ostatní uzly na posledním uzlu. Informace, zda závislost mezi dvěma uzly odpovídá tomuto pravidlu, může být rys, který budou parsery sledovat. * Rozchodit podporu clusteru v makefilech, abych nemusel MST parser pouštět ručně zvlášť (''qmake''). * Vyzkoušet neprojektivní parsing MST parserem. * Zjistit, proč je tolik chyb v syntaktickém značkování, a vylepšit ho. Třeba pomocí nějakého toolkitu pro strojové učení (Mallet apod.) Uvědomit si, že na jednom slovesu zřejmě nemohou viset dvě káčka se stejnými čísly (karma-karta). Taky že většina sloves asi vyžaduje k1. * Více si pohrát s konfigurací Malt parseru. 7 algoritmů už jsem vyzkoušel, ale některé z nich mají ještě další parametry (práce s kořenem apod.), které jsem neměnil. * Vyhodnotit křivku učení. * Vyhodnotit požadavky na procesor, paměť a disk (je třeba nejdříve rozchodit skript). * Frekvenční slovníky, abych si trochu udělal představu o častých slovech, případně o jejich syntaktických zvláštnostech. * Průzkum dat: jak dlouhé jsou věty? Indové v dokumentaci nějaká čísla uvádějí, ale tam se slova počítají včetně záložek a možná i včetně interpunkce, takže neodpovídají počtu uzlů, které vidím v treebanku. * Neučit se na hindštině a bengálštině dohromady? Jsou to přece podobné jazyky a data by se významně zvětšila! ===== Průzkum dat ===== Jak je zvykem, máme k dispozici data pro (d)trénink, dtest a etest (ta poslední jsou slepá, aspoň zatím). Každý datový soubor je k dispozici jednak s automaticky doplněnou (a zjednoznačněnou) morfologií (lemma, značka POS, morfologické kategorie), jednak bez ní (tj. na morfologické rovině pouze slovní tvar a značka chunku, ta by ale zřejmě měla být přiřazená ručně). Každý z uvedených souborů je ještě k dispozici jednak ve formátu CoNLL 2006, jednak v SSF (Shakti Standard Format, pro Indy je domovský, takže by stálo za to zjistit, zda se z něj převodem do CoNLL něco neztrácí). Následující statistiky pocházejí ze souborů pro dtrénink s automatickou morfologií: | Jazyk | Výskytů slov | Tvarů | Lemmat | ChunkPOS | POS | POS+case+postpos | FEATS | | hindština | 13779 | 3973 | 3134 | 10 | 33 | 297 | 714 | | bengálština | 6449 | 2997 | 2336 | 14 | 30 | 398 | 367 | | telugština | 5494 | 2462 | 1403 | 12 | 31 | 409 | 453 | Statistiky v tabulce byly získány následujícím příkazem: $TOOLS/conll_pocet_hodnot_sloupec.pl 4 < hi/dtrain.mconll ==== Naivní telugu ==== V telugských stromech jsem vypozoroval extrémní důsledek slovosledu SOV: poměrně často se stává, že poslední slovo věty visí na kořeni (typicky je to zřejmě sloveso) a většina ostatních slov visí na něm. Pro hindštinu a bengálštinu už to neplatí. Následující tabulka ukazuje podíl uzlů v jednotlivých datových souborech, které visely "naivně telugsky" (tj. pokud šlo o poslední uzel, visel na kořeni, jinak na posledním uzlu). Vzhledem k tomu, že na telugštině jinak dosahuju nejnižší úspěšnosti, by se tohle mělo nějak využít. | Jazyk | dtrain | dtest | | hi | 35.71 | 34.64 | | bn | 39.52 | 44.14 | | te | 73.75 | 76.89 | ==== Nová data pro druhé kolo ==== Pro druhé vyhodnocení pořadatelé připravili upravená data "with courser tags". Ukázalo se, že nejde o lepší informaci na morfologické rovině, která by případně mohla parsing usnadnit. Jde o syntaktické značky, které má parser produkovat spolu se závislostní strukturou. Otázka je, jestli jsou nové značky jednodušší, nebo složitější než ty staré, ale každopádně by měly ovlivnit výhradně značkovanou úspěšnost. ===== Analýza chyb ===== Takhle se z morfologických indických dat vyrobí soubor pro Tred, který obsahuje indické písmo místo WX: cat hi/dtest.rmconll | conll_wc2utf.pl -l hi | $TOOLS/conll2csts.pl -y 2006 -l hi | perl -pe 's/\S+\t//; s/\t.*? hi/dtest.fs Důležitou součástí výše uvedeného příkazu je perlový kód, který maže tabulátory ze značek, jinak se na výsledek nedá v Tredu koukat. Tady je varianta pro výstup parseru: cat hi/dtest.voted.rconll | conll_wc2utf.pl -l hi | $TOOLS/conll2csts.pl -y 2006 -l hi | perl -pe 's/\S+\t//; s/\t.*? hi/dtest.voted.fs A takhle spojíme vzorovou anotaci s výstupem parseru, abychom viděli chyby: conll_pokusy.pl -l hi -t -g hi/dtest.mconll -s hi/dtest.voted.rconll | cstsfs.pl -s dzchyby > hi/dtest.voted.fs Tady je ještě jedna alternativa (pozor, tohle je pro změnu okopírováno z Windows). Kromě toho, že jsem opravil některé chyby v ''brahmi.pm'' (což se na volání nijak neprojeví), je teď nově možnost vybrat si ze dvou variant výstupní transliterace do latinky. ''-t sci'' vyvolá vědeckou transliteraci, která se hodí do článků, ale nehodí se pro čtení v Putty, protože používá kombinovanou diakritiku. Pro čtení v Putty použijeme ''-t putty''. C:\Documents and Settings\Dan\Dokumenty\Lingvistika\Projekty\icon-parsing\work>set TOOLS="C:\Documen ts and Settings\Dan\Dokumenty\Lingvistika\Projekty\padapt\parsingroot\tools" C:\Documents and Settings\Dan\Dokumenty\Lingvistika\Projekty\icon-parsing\work>perl conll_pokusy.pl -l te -t sci -g te/dtest.mconll -s te/dtest.voted.rconll | perl %TOOLS%/cstsfs.pl -s dzchyby > te/dt est.voted.1.fs Není pravda, že ze značky POS jednoznačně vyplývá značka chunku. Proto bych měl parserům poskytnout obě značky, může jim to pomoct. Např. v bengálské větě "(3) তবে / tabé সুদীপ / sudípa ওকে / óké একদিন / ékadina আড়ালে / áđa়াlé ডেকে / đéké বলেছিল / baléčhila কৌতূহল / kautúhala দেখালে / dékhálé তুমি / tumi উঁচুতে / um̃čuté উঠতে / uţhaté অনিমেষ / animéša" jsou slova "déké" a "dékhálé" značena jako "VGNF|VM" (zřejmě gerundium), zatímco "baléčhila" a "uthaté" jsou "VGF|VM". Pokud parser u všech vidí jen "VM", pak není divu, že v té větě nasekal několik divokých chyb. V hindštině se často na chybách podílí uzel NULL. Spočítat, kolik takových uzlů ve kterém jazyce je. Přinejmenším častá slova by měla být pro parsery viditelná jako samostatný rys uzlu. Např. hindské "कि / ki" ("že") se mi zavěsilo špatně a kdo ví, jestli to není jen proto, že parser viděl pouze značku "CC". Podobně "तो / tó" má taky značku "CC", ale jeho zavěšování asi bude o dost jiné. Úspěšnost přes 85 % je poměrně vysoká a je těžké v těch občasných chybách vysledovat nějaké pravidlo. Přinejmenším v hindštině se mi ale zdá, že často jde o chyby se slovesy či spojkami (koordinace sloves) a často na velkou vzdálenost. Příklad problému s koordinací, stejného, jaký měl DZ parser na češtině: "(143) भाई / bháí और / aura भाभी / bhábhí उसके / usaké अच्छा / aččhá व्यवहार / vjavahára करते / karaté". "bháí aura bhábhí" je jasná koordinace dvou podstatných jmen, která pak dohromady tvoří podmět slovesa. Parser je sice správně spojil do koordinace, pak už ale asi viděl jen spojku "aura", zapomněl na podstatná jména pod ní, vzpomněl si, že spojky také spojují celé klauze, a pověsil ji na kořen. Je potřeba přinejmenším Malt parseru, ale pokud to jde, tak i MST parseru předhodit podrobnější rysy, aby parser mohl pracovat zvlášť např. s lemmatem a zvlášť s pádem a sám se rozhodnout, ve kterém případě mu co pomáhá víc. ===== Výsledky ===== První výsledky DZ Parseru na vývojových datech: hi: A 1250 - G 554 - P 0.4432 bn: A 811 - G 408 - P 0.5031 te: A 675 - G 249 - P 0.3689 Fuj! Když jsem vynechal morfologii, tj. použil jsem pouze slovní druh, je to lepší (jednak data nejsou tak řídká, jednak morfologie byla označkovaná automaticky, tj. s chybami, zatímco slovní druhy jsou vyznačené ručně): hi: A 1250 - G 775 - P 0.6200 bn: A 811 - G 576 - P 0.7102 te: A 675 - G 476 - P 0.7052 Malt Parser na stejné úloze: java -Xmx2g -jar ../../../malt-1.3/malt.jar -c malt -i hindi_training.ssf.conll -m learn java -Xmx2g -jar ../../../malt-1.3/malt.jar -c malt -i hindi_developmet.ssf.conll -o out.conll -m parse $TOOLS/eval07.pl -g hindi_developmet.ssf.conll -s out.conll | more hi: bez značek 0.8184 (1023/1250), se značkami 0.5520 bn: bez značek 0.8471 ( 687/ 811), se značkami 0.6042 te: bez značek 0.8089 ( 546/ 675), se značkami 0.4474 MST Parser na stejné úloze: Přinejmenším pro hindštinu potřebuje větší paměť (-Xmx4000m stačilo, výchozích 1800 ne). hi: bez značek 0.8032 (1004/1250), se značkami 0.5480 bn: bez značek 0.8200 ( 665/ 811), se značkami 0.6091 te: bez značek 0.7763 ( 524/ 675), se značkami 0.4667 Postřehy: - Kvůli DZ Parseru je nutné něco udělat proti převádění velkých písmen na malá. U zvolené transliterace z indických písem totiž velikost písmen hraje roli. - Data jsou příliš malá, takže je potřeba nějak prořezat informaci ve značkách. - Parser, který pustím na soutěžní testovací data, bych měl určitě natrénovat na sjednocení trénovacích a vývojových dat! V tomhle množství je každá stovka vět dobrá! - Otázka je, zda po nás organizátoři chtějí také odhadnout značky závislostí. Asi jo. - Hindská (a pravděpodobně i ostatní) data obsahují neprojektivity, takže parsery, které to umí (Malt i MST) bych měl pouštět v neprojektivním režimu. Otázky: - Jaké je složení morfologických značek? Co je pád, například? - Jaká je míra neprojektivity? - Jaká je průměrná délka věty? - Jak moc se jednotlivé parsery liší v odpovědích? Úkoly: - Uklidit si na disku, vyrobit si makefile. Pozor! Když volám Malt parser ze složky s daty, nenajde cestu ke svému souboru s definicemi rysů a má mnohem menší úspěšnost (s výjimkou telugštiny, kde je z nějakého důvodu úspěšnost stejná). Hlasování parserů nad formátem CoNLL. - Načíst větu postupně ze 3 otevřených souborů s výstupy 3 parserů. - Už při načítání výstupy slít, takže u každého slova mám 3 odkazy na rodiče podle 3 parserů. Současně si vybudovat i síť opačných odkazů, od rodičů k dětem. - Abychom zajistili, že graf, který vybudujeme, bude strom, nedovolíme v každém kroku přidat libovolný uzel. Místo toho se budeme snažit postupovat od kořene k listům. - Budeme udržovat dvě skupiny uzlů, hotové a čekající. Hotové uzly jsou už zařazené do stromu, čekající ještě ne. - Na začátku je hotový pouze kořen stromu. - U všech čekajících uzlů provést hlasování o jejich rodiči. Každý parser disponuje tolika hlasy, jaká byla jeho úspěšnost na vývojových datech. Vítězný rodič v tuto chvíli ještě nemusí být hotový. - Nyní opakovaně procházet čekající uzly. Ty, jejichž vítězný rodič už je hotový, přidat do stromu. To celé opakovat, dokud je možné přidat nějaký čekající uzel. - Je možné, že vítězní rodiče některých čekajících uzlů tvoří cyklus, a proto se do stromu zatím nedostaly. - V tom případě najít uzel, u kterého napácháme nejméně škody tím, že ho pověsíme na jiného než vítězného rodiče. (Tohle je podobný princip, jaký používá i Ryan McDonald uvnitř MST parseru, ne?) Musí to být rodič, který je už hotový, ale při splnění této podmínky má nejvyšší možný počet hlasů. Asi se teoreticky může stát, že žádný parser nedal hlas žádné hraně, která by zrušila cyklus, v tom případě budeme muset prostě nějaký uzel vylosovat. Po přidání tohoto rodiče do stromu bude možné přidat i celou jeho skupinku (cyklus). Potom totéž postupně uděláme i s ostatními cykly. - Paralelně je nutné ještě rozhodnout o syntaktické značce pro danou závislost. Tady použijeme opět vážené hlasování jednotlivých parserů. Mohli bychom výsledek také ovlivňovat tím, který parser vyhrál hlasování o zavěšení uzlu, ale to by bylo komplikované. - Na standardní výstup vypsat větu ve formátu CoNLL, ale s novými hodnotami HEAD a DEPREL. Porovnání úspěšností parserů nad jednotlivými jazyky: Úspěšnost nalezení rodiče, bez syntaktické značky (Malt:MST:DZ) hi:8184:8032:6200 1:0.98:0.76 bn:8471:8200:7102 1:0.97:0.84 te:8089:7763:7052 1:0.96:0.87 Úspěšnost přiřazení syntaktické značky (Malt:MST:DZ) hi:5728:5824:3776 1:1.02:0.66 bn:6215:6289:5376 1:1.01:0.87 te:4904:5111:4267 1:1.04:0.87 Když použiju část informace z morfologie, DZ Parser si vede mnohem lépe! (Na hindštině asi 74% místo 62.) :-( Bohužel se ukazuje, že to platí pouze pro hindštinu. Bengálština i telugština se výrazně zhorší. Otázka je, jestli by si lépe vedly i Malt parser a MST parser, ale to vyzkouším až později. Pozoruhodné je, že zhoršený DZ Parser zlepšuje výsledek hlasování, na kterém se podílí! Nové váhy parserů při hlasování (20.10.2009 13:26, DZ parser teď na všechno používá pád a záložku, Malt parser používá POSTAG s pádem a záložkou pro hindštinu, jinde používá CPOSTAG, MST Parser používá všude POSTAG s pádem a záložkou): unlabeled MST:MALT:DZ hi 8616:8584:7512 bn 8570:8471:5438 te 7985:8089:4578 labels MST:MALT:DZ hi 6816:6704:5960 bn 6967:6215:5314 te 5526:4904:4400 ===== Neprojektivity ===== 21:57 lrc-two:/ha/work/people/zeman/icon-parsing/work> cat hi/dtrain.conll hi/dtest.conll | $TOOLS/neproj.pl slov = 15025 neproj = 275 podil = 0.0183028286189684 vet = 1651 neproj = 230 podil = 0.13930950938825 22:05 lrc-two:/ha/work/people/zeman/icon-parsing/work> cat bn/dtrain.conll bn/dtest.conll | $TOOLS/neproj.pl slov = 7260 neproj = 70 podil = 0.00964187327823691 vet = 1130 neproj = 62 podil = 0.0548672566371681 22:05 lrc-two:/ha/work/people/zeman/icon-parsing/work> cat te/dtrain.conll te/dtest.conll | $TOOLS/neproj.pl slov = 6169 neproj = 28 podil = 0.00453882314799805 vet = 1606 neproj = 21 podil = 0.0130759651307597 Předběžný pokus s neprojektivní analýzou hindštiny Malt parserem ukazuje zřetelné zhoršení: Labeled attachment score: 641 / 1250 * 100 = 51.28 % Unlabeled attachment score: 947 / 1250 * 100 = 75.76 % Label accuracy score: 685 / 1250 * 100 = 54.80 % ===== Parsovací algoritmy Malt parseru ===== Zatím jsem neměnil root handling u Nivreho algoritmů (-r strict|relaxed|normal) a allow shift/root u Covingtona (-cs, -cr). Tohle jsou nejlepší hodnoty, kterých jsem dosáhl. Na každém jazyku vyhrál jiný algoritmus. Na hindštině Malt parser opět překonal MST, takže bude potřeba upravit váhy při hlasování. Současný výsledek Malt parseru je lepší než dosud nejlepší výsledek dosažený hlasováním! hi 87.60 stacklazy bn 85.57 covproj te 81.04 stackeager ==== nivrestandard ==== Hindština i bengálština vyšla zřetelně lépe než nivreeager, telugština si lehce pohoršila. Thu Nov 19 18:41:43 CET 2009 /net/work/people/zeman/icon-parsing/work/hi/dtest.malt.eval.txt Labeled attachment score: 812 / 1250 * 100 = 64.96 % Unlabeled attachment score: 1082 / 1250 * 100 = 86.56 % Label accuracy score: 847 / 1250 * 100 = 67.76 % Thu Nov 19 18:41:45 CET 2009 /net/work/people/zeman/icon-parsing/work/bn/dtest.malt.eval.txt Labeled attachment score: 491 / 811 * 100 = 60.54 % Unlabeled attachment score: 693 / 811 * 100 = 85.45 % Label accuracy score: 509 / 811 * 100 = 62.76 % Thu Nov 19 18:41:46 CET 2009 /net/work/people/zeman/icon-parsing/work/te/dtest.malt.eval.txt Labeled attachment score: 304 / 675 * 100 = 45.04 % Unlabeled attachment score: 541 / 675 * 100 = 80.15 % Label accuracy score: 339 / 675 * 100 = 50.22 % ==== covproj ==== Bengálština ještě trochu lepší, možná nesignifikantně. Ostatní ne. Thu Nov 19 19:47:14 CET 2009 /net/work/people/zeman/icon-parsing/work/hi/dtest.malt.eval.txt Labeled attachment score: 801 / 1250 * 100 = 64.08 % Unlabeled attachment score: 1079 / 1250 * 100 = 86.32 % Label accuracy score: 836 / 1250 * 100 = 66.88 % Thu Nov 19 19:47:15 CET 2009 /net/work/people/zeman/icon-parsing/work/bn/dtest.malt.eval.txt Labeled attachment score: 500 / 811 * 100 = 61.65 % Unlabeled attachment score: 694 / 811 * 100 = 85.57 % Label accuracy score: 516 / 811 * 100 = 63.63 % Thu Nov 19 19:47:15 CET 2009 /net/work/people/zeman/icon-parsing/work/te/dtest.malt.eval.txt Labeled attachment score: 303 / 675 * 100 = 44.89 % Unlabeled attachment score: 542 / 675 * 100 = 80.30 % Label accuracy score: 330 / 675 * 100 = 48.89 % ==== covnonproj ==== Zlepšila se hindština. Bengálština se zhoršila, telugština zůstala. Thu Nov 19 21:21:46 CET 2009 /net/work/people/zeman/icon-parsing/work/hi/dtest.malt.eval.txt Labeled attachment score: 811 / 1250 * 100 = 64.88 % Unlabeled attachment score: 1087 / 1250 * 100 = 86.96 % Label accuracy score: 843 / 1250 * 100 = 67.44 % Thu Nov 19 21:21:46 CET 2009 /net/work/people/zeman/icon-parsing/work/bn/dtest.malt.eval.txt Labeled attachment score: 492 / 811 * 100 = 60.67 % Unlabeled attachment score: 682 / 811 * 100 = 84.09 % Label accuracy score: 510 / 811 * 100 = 62.89 % Thu Nov 19 21:21:47 CET 2009 /net/work/people/zeman/icon-parsing/work/te/dtest.malt.eval.txt Labeled attachment score: 305 / 675 * 100 = 45.19 % Unlabeled attachment score: 542 / 675 * 100 = 80.30 % Label accuracy score: 329 / 675 * 100 = 48.74 % ==== stackproj ==== Není nejhorší, ale taky v ničem nejlepší. Thu Nov 19 21:29:06 CET 2009 /net/work/people/zeman/icon-parsing/work/hi/dtest.malt.eval.txt Labeled attachment score: 830 / 1250 * 100 = 66.40 % Unlabeled attachment score: 1082 / 1250 * 100 = 86.56 % Label accuracy score: 871 / 1250 * 100 = 69.68 % Thu Nov 19 21:29:06 CET 2009 /net/work/people/zeman/icon-parsing/work/bn/dtest.malt.eval.txt Labeled attachment score: 510 / 811 * 100 = 62.89 % Unlabeled attachment score: 690 / 811 * 100 = 85.08 % Label accuracy score: 524 / 811 * 100 = 64.61 % Thu Nov 19 21:29:07 CET 2009 /net/work/people/zeman/icon-parsing/work/te/dtest.malt.eval.txt Labeled attachment score: 309 / 675 * 100 = 45.78 % Unlabeled attachment score: 546 / 675 * 100 = 80.89 % Label accuracy score: 339 / 675 * 100 = 50.22 % ==== stackeager ==== Přestože umožňuje neprojektivity, hindština i bengálština jsou výrazně horší. Zato se vytáhla telugština, kde neprojektivity téměř nejsou! Thu Nov 19 21:44:15 CET 2009 /net/work/people/zeman/icon-parsing/work/hi/dtest.malt.eval.txt Labeled attachment score: 761 / 1250 * 100 = 60.88 % Unlabeled attachment score: 1022 / 1250 * 100 = 81.76 % Label accuracy score: 813 / 1250 * 100 = 65.04 % Thu Nov 19 21:44:16 CET 2009 /net/work/people/zeman/icon-parsing/work/bn/dtest.malt.eval.txt Labeled attachment score: 498 / 811 * 100 = 61.41 % Unlabeled attachment score: 680 / 811 * 100 = 83.85 % Label accuracy score: 514 / 811 * 100 = 63.38 % Thu Nov 19 21:44:17 CET 2009 /net/work/people/zeman/icon-parsing/work/te/dtest.malt.eval.txt Labeled attachment score: 303 / 675 * 100 = 44.89 % Unlabeled attachment score: 547 / 675 * 100 = 81.04 % Label accuracy score: 336 / 675 * 100 = 49.78 % ==== stacklazy ==== Na hindštině je to maximum, ostatní se zhoršily. Thu Nov 19 21:52:53 CET 2009 /net/work/people/zeman/icon-parsing/work/hi/dtest.malt.eval.txt Labeled attachment score: 823 / 1250 * 100 = 65.84 % Unlabeled attachment score: 1095 / 1250 * 100 = 87.60 % Label accuracy score: 853 / 1250 * 100 = 68.24 % Thu Nov 19 21:52:54 CET 2009 /net/work/people/zeman/icon-parsing/work/bn/dtest.malt.eval.txt Labeled attachment score: 480 / 811 * 100 = 59.19 % Unlabeled attachment score: 687 / 811 * 100 = 84.71 % Label accuracy score: 496 / 811 * 100 = 61.16 % Thu Nov 19 21:52:55 CET 2009 /net/work/people/zeman/icon-parsing/work/te/dtest.malt.eval.txt Labeled attachment score: 307 / 675 * 100 = 45.48 % Unlabeled attachment score: 544 / 675 * 100 = 80.59 % Label accuracy score: 336 / 675 * 100 = 49.78 %