[ Skip to the content ]

Institute of Formal and Applied Linguistics Wiki


[ Back to the navigation ]

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
user:zeman:malt-parser [2010/04/27 16:21]
zeman Doběhlo jlibsvm 10000.
user:zeman:malt-parser [2013/07/11 22:15] (current)
zeman Odstraněn záznam o ladění před 3 lety.
Line 1: Line 1:
-====== Malt parser ======+====== Malt parser: pokusy s PDT 2.0 ======
  
 http://maltparser.org/ http://maltparser.org/
  
-Rychlý úvod do práce s Malt parserem, který tu dřív byl, už neplatí, protože se týkal starého Malt parseru 0.4 (céčková implementace)Nyní už máme 1.3 (javová implementace)Až se to usadí, budou k ní spouštěcí skripty v repozitáři Parsing v SVN.+Od května 2012 používám Malt Parser 1.7.1 z ''/home/zeman/nastroje/parsery/maltparser-1.7.1''.
  
-===== Pokusy s PDT 2.0 =====+Podle Joakima trénování na celém PDT trvá 3 až 5 dní, a to ještě jen při použití splitting tricku (bez něj několik týdnů)Trénování SVM má kvadratickou složitost vzhledem k počtu trénovacích příkladů; těch z PDT vypadnou asi 3 milióny. (S Joakimem jsem se o tom bavil na jaře 2010 a šlo o Malt Parser 1.3. Tehdy jsem také zkoušel trénovat bez splitting tricku. Jeden experiment běžel i 60 dní, řada experimentů ale vůbec nedoběhla, protože jejich stroj cestou chcípnul.)
  
-Malt 1.3. Podle Joakima trénování na celém PDT trvá 3 až 5 dní, a to ještě jen při použití splitting triku (bez j několik týdnů). Trénování SVM má kvadratickou složitost vzhledem k počtu trénovacích íkladů; těch z PDT vypadnou asi 3 milióny.+Celá trénovací data mají 68562 vě(někde mám chybně uvedeno 68563 kvůli nejasnostem s počítáním od nuly a od jedničky, ale teď jsem to kontroloval a dvojím způsobem epočítával prázdné řádky v souboru ''dtrain.conll'' a je to opravdu 68562). Testování je vždy, když není řečeno jinak, na celém dtestu, tedy 9270 vět. Tam, kde je explicitně uvedeno testování na etestu, jde o 10148 vět; v tom případě pak trénuju na sjednocení trénovacích a d-test dat, celkem 77832 vět.
  
-Trénování bez "splitting tricku" na celých trénovacích datech.+===== Jak se to pouští? =====
  
-| Algoritmus | Délka trénování | Délka parsingu | Rychlost parsingu | Úspěšnost | +  * Přejít do adresáře ''/net/work/people/zeman/parsing/projects/maltpdt''popř. si nejdřív někam vybalit SVN parsing a pak přejít do složky ''projects/maltpdt''. 
-| nivreeager | 24 dní 17 hodin 13 minut (2135575 s) | 180062 s (50:01 hodin) | 1 věta 19,4 s | 80,73 % | +  * Skript ''getdata.csh'', případně ''getdata.gold.csh'' (pokud chceme použít ručně zjednoznačněnou morfologii)nám vyrobí místní kopii trénovacích a testovacích datpřevedenou do formátu CoNLL. Jsou to data z PDT 2.0 (train, dtest a etest na analytické rovině) a já už je mám na toto místo zkopírované. 
-| nivrestandard | 32 dní 16 hodin 47 minut (2825227 s) | 225021 s (62:30 hodin) | 1 věta / 24,3 s | 79,98 % | +  * Složka ''/net/work/people/zeman/parsing/projects/maltpdt/experiments'' obsahuje pokusyve kterých jsem se snažil co nejvíce přiblížit nastaveníkteré se nejvíce osvědčilo Joakimovi a jeho týmu v roce 2009Příslušné soubory s definicemi rysů jsou ve složce ''/net/work/people/zeman/parsing/malt-parser/marco-kuhlmann-czech-settings''. Je tam také skript ''conll-pdttags2conll.pl'', kterým se patnáctimístné poziční značky PDT převedou na takové seznamy rysů a hodnot, jaké se používaly v soutěži CoNLL 2009. 
-| covproj | 60 dní 15 hodin 28 minut (5239706 s) | 348001 s (96:40 hodin) | 1 věta 37,5 s | 79,69 % | +  * Dosud neexistuje žádný Makefile. Pouštělo se to pomocí skriptu ''all.pl'', který rovnou odesílal úlohy na cluster. Každá složka s odlišným pokusem má svou mutaci tohoto skriptu. Každá odeslaná úloha se skládá ze tří částíučenírozbor testovacích dat a vyhodnocení.
-| covnonproj | Skončilo restartem fireball6 někdy lednu nebo únoru 2010''/tmp'' bohužel nezůstala po výpočtu žádná stopa. | | | | +
-| stackproj | 42 dní 12 hodin 55 minut (3675303 s) | 183676 s (51:01 hodin) | 1 ta / 19,8 s | 78,49 % | +
-| stacklazy | Skončilo chybou Java VM (''memcpy'') po 36 dnech 14 hodinách 21 minutách | | | | +
-| stackeager | 39 dní 11 hodin 38 minut (3375472 s) | 227927 s (63:19 hodin) | 1 věta / 24,6 s | 82,93 % |+
  
-Trénování na části trénovacích dat (prvních N vět). Testování je vždy na celém dtestu, tedy 9270 vět.+===== Co dál? =====
  
-| N | Délka trénování | Délka parsingu | Rychlost parsingu | Úspěšnost | +  * Upravit švédskou definici rysůaby fungovala i s algoritmy ''nivrestandard''''nivreeager''''covproj'' a ''covnonproj''. Vše vyzkoušet opět na různě velkých trénovacích datech. Nikde není dánože právě ''stacklazy'' musí být nejúspěšnější algoritmus na PDT. 
-| 1000 | 5 minut | 1 hodina | 2,5 věty / | 71,49 % | +  * Odladit ''train.pl''aby se výsledný soubor ''.mco'' dal rozbalovat. Možná mu vadí pouze ".mco" u volby ''-c''
-| 2000 | 24 minut | 5522 s (1,5 hodiny) | 1,7 věty / s | 75,02 % | +  * Jestli nakonec nějak prorazímbude potřeba opět učesat obalovací skripty. Mj. jsem přišel na tože ve tšině svých skriptů používám jako dočasný adresář ''/tmp'' místo Milanem důrazně doporučeného ''/mnt/h/tmp''. Např. na tauri10 jsem tak počmáral 4 GB a proces skončil, protože příslušný svazek byl plný. Tohle by se mj. mělo opravit i u skriptů pro Joshuu a dalších. Jinak jsem taky mohutně čachroval s žádostí o příděl paměti na clusteru (týká se i skriptu ''qsub.csh''), s konfigurací Maltu atd. 
-| 5000 | 4 hod 40 min | 9914 s (2 3/4 hod) | 0,9 věty / s | 77,72 % | +  * Vyhodnotit to ještě i na e-testu a připsat to na stránku o českém parsingu. 
-| 10000 | 22 hod 05 min | 21865 s (6 hodin) | 0,4 věty / s | 79,28 % | +  * Zkusit hlasování pětitisícových kusů.
-| 20000 | 53 hod 33 min | 47822 s (13 1/4 hodin) | 1 věta / 5,2 s | 80,71 % | +
-| 50000 | 19 dní 1 hod 27 min | 76428 s (21 1/4 hodin) | 1 ta 8,2 s | 82,76 % | +
-| 68563 | Skončilo restartem sol5 po 36 dnech. V ''/tmp'' bohužel nezůstala po výpočtu žádná stopa| | | |+
  
-Podívat se na LEMMA místo FORM?+===== Nové výsledky s Malt Parserem 1.7 =====
  
-==== Výpočetní náročnost ====+Experimenty probíhaly v červnu 2013. Měl jsem dva cíle: 1. Natrénovat nové modely, protože ty staré nejsou kompatibilní s novou verzí parseru, a 2. získat výsledky na e-testu, protože dosud jsem pracoval jen s d-testem. I když jsem novou verzi parseru pouštěl se stejnými parametry jako před třemi lety tu starou, dostal jsem jiné výsledky (nepatrně horší).
  
-Na jakých strojích to běží (LRC): +D-test (9270 vět): 
-(poznámky typu "ale proces zabírá jen" se týkají prosincových trénování se splitting trickem a s Danovým nastavením).+LAS = 80,04 % 
 +UAS = 85,96 % 
 +LAB = 86,43 % 
 +Běželo na stroji lucifer5 (Intel Xeon 2394 GHzs vyhrazenými 30 GB paměti
 +learning time (na trénovacích datech= 139 hodin, tjnecelých 6 dní 
 +parsing time = 7 hodin (25559301 ms), tj. 1 věta průměrně za 2,76 s
  
-=== orion7 === +E-test (10148 vět): 
-procesor 64bit Intel Xeon 2 GHz +LAS 79,80 % 
-paměť 32 GB, ale proces zabírá jen 2,2 GB +UAS 85,76 % 
-Je to náročné na diskové operace?+LAB 86,24 % 
 +Běželo na stroji hydra1 (AMD Opteron 2518 GHz) s vyhrazenými 30 GB paměti: 
 +learning time (na trénovacích a d-test datech) = 221 hodin, tj. něco přes 9 dní 
 +parsing time = 9 hodin (34135285 ms), tj. 1 věta průměrně za 3,36 s
  
-=== sol5 ==+===== BEST: Malt parser 1.3javová implementace libsvmsplitting trick =====
-procesor 64bit dual core AMD Opteron 2 GHz +
-paměť 16 GBale proces zabírá jen 4,1 GB+
  
-==== Nastavení od Švédů ==== +Vyžaduje více času a paměti než céčková implementace, ale nepadáPodle dokumentace může dojít k drobným odchylkám v úspěšnosti způsobeným odlišným zpracováním racionálních číselTato sada pokusů používala splitting trickjinak by trénování v rozumném čase nedoběhloDole mám ještě jednu, u které si nejsem jist, čím esně se její nastavení lišíZdůrazňuje právě splitting trickProtože rozdíl nemůže tkvět v tomzda vůbec byl splitting trick nasazenbude pravděpodobně v tom, podle jaké hodnoty se lilo. Předpokládám, že tady to byl slovní druh, zatímco tam (jak se tam říká) poddruh.
- +
-26.3.2010 po měsíci další pokus pustit to na datech upravených stejným způsobem se stejnými rysy jako Joakim a Marco. Zpočátku trénink pouze na 1000 větách. Na cosmosu běží paralelně dvě úlohy, které se liší pouze přidělenou pamětí. První úloha dostala 30 GB (na clusteru rezervováno 50) a využila je. Druhá úloha dostala 180 GB, využila zatím 69, ale už dlouho se na nich drží. +
- +
-28.3.2010: Zjistil jsem, že při převodu dat do formátu, který měl být shodný s Marcovým, jsem omylem vypustil všechna zalomení vět, tj. soubor obsahoval jednu větu o 16001 slovech, navíc nejednoznačně číslovaných. Tak to už se ani nedivím, že to parseru nedělalo dobře. +
- +
-<code>foreach (1000 2000 5000 10000 20000 50000) +
-  $PARSINGROOT/malt-parser/marco-kuhlmann-czech-settings/conll-pdttags2conll.pl < dtrain-$i.conll > dtrain-$i.conll2009tags.conll +
-end +
-foreach i (dtrain dtest) +
-  $PARSINGROOT/malt-parser/marco-kuhlmann-czech-settings/conll-pdttags2conll.pl < $i.conll > $i.conll2009tags.conll +
-end +
-foreach i (25000 30000 35000 40000 45000 55000 60000 65000) +
-  split_conll.pl < dtrain.conll2009tags.conll -head $i dtrain-$i.conll2009tags.conll /dev/null +
-end</code> +
- +
-Učení: +
- +
-<code>qsub.csh mf=31g $PARSINGROOT/malt-parser/scripts/train.pl '<' dtrain-1000.conll2009tags.conll1 '>' d.pokus1000-30g-clibsvm.mco</code> +
- +
-Rozbor: +
- +
-<code>qsub.csh mf=31g $PARSINGROOT/malt-parser/scripts/parse.pl -g d.pokus1000-30g-clibsvm.mco '<' dtest.conll2009tags.conll '>' dtest.malt-pokus1000-30g-clibsvm.conll</code> +
- +
-Vyhodnocení: +
- +
-<code>$PARSINGROOT/tools/conll-eval07.pl -g dtest.conll2009tags.conll -s dtest.malt-pokus1000-30g-clibsvm.conll > dtest.malt-pokus1000-30g-clibsvm.eval.txt</code> +
- +
-Trénování na části trénovacích dat (prvních N vět). Testování je vždy na celém dtestu, tedy 9270 vět. +
- +
-| N | TÚloha | Délka trénování | PÚloha | Délka parsingu | Rychlost parsingu | Úspěšnost | +
-| 1000 | | 1 minuta | | 1248 s = 20:48 min | 1 věta / 0,13 s | 74,63 % | +
-| 2000 | | 4 minuty | | 1885 s = 31:25 min | 1 věta / 0,20 s | 77,73 % | +
-| 5000 | | 30 minut | | 5534 s = 1:32 hod | 1 věta / 0,60 s | 80,18 % | +
-| 10000 | | 1:30 hod | | 7171 s = 2:00 hod | 1 věta / 0,77 s | 82,11 % | +
-| 20000 | | 10:09 hod | | 17139 s = 4:45 hod | 1 věta / 1,85 s | 83,65 % | +
-| 25000 | 984089 | 12:12 hod | 984241 | 16031 s = 4:27 hod | 1 věta / 1,73 s | 84,24 % | +
-| 30000 | 984090 | 21:54 hod | 984266 | 19280 s = 5:21 hod | 1 věta / 2,08 s | 84,54 % | +
-| 35000 | 984091 | 21:09 hod | 984242 | 22018 s = 6:07 hod | 1 věta / 2,38 s | 84,89 % | +
-| 40000 | 984092 | spadlo na ''sdm0.003.libsvm.mod'' | | | | | +
-| 45000 | 984093 | 38:18 hod | 1008955 | 26853 s = 7:28 hod | 1 věta / 2,90 s | 85,35 % | +
-| 50000 | 984030 | 49:55 hod | 984336 | 37224 s = 10:20 hod | 1 věta / 4,02 s | 85,47 % | +
-| 55000 | 984094 | spadlo na ''sdm0.004.libsvm.mod'' | | | | | +
-| 60000 | 984095 | spadlo na ''sdm0.004.libsvm.mod'' | | | | | +
-| 65000 | 984096 | spadlo na ''sdm0.004.libsvm.mod'' | | | | | +
-| 68563 | | spadlo na ''sdm0.004.libsvm.mod'' | | | | | +
- +
-==== Proč trénování větších modelů padá? ==== +
- +
-''sdm0.004.libsvm.mod'' je dílčí model pro hodnotu ''CPOSTAG'' číslo 4. Značky jsou číslovány podle pořadí, v&nbsp;jakém se v&nbsp;trénovacích datech objevily. Pokud tedy všechny podmnožiny trénovacích dat, které zkouším, začínají na začátku trénovacích dat, mají číslování značek stejnéČíslování je také možné ověřit tak, že rozbalíme model, vznikne stejnojmenná složka, v&nbsp;ní se pak podíváme do souboru ''symboltables.sym'' na část ''CPOSTAG'': +
- +
-<code>java -jar ~/nastroje/parsery/malt-1.3/malt.jar -c model -m unpack +
-cd model +
-less symboltables.sym</code> +
- +
-Až na jednu výjimku trénování spadlo vždy i budování ''sdm0.004.libsvm.mod'' a vždy na větších trénovacích datechTento model patří podstatným jménům (přesněji: situacím, kdy na vrcholu zásobníku leží podstatné jméno)Tento model, resp. jeho vstupní data, jsou také zřejmě vždy největší. Není sice asi problém s&nbsp;dostupností operační paměti (''svm-train'' spotřebovává řádově stovky megabajtůpřitom má k dispozici desítky gigabajtů)ale vnitřní struktury libsvm asi na tak velká data nejsou připraveny. +
- +
-Joakim navrhuje, abychom zkusili dělení zjemnitnapř. místo CPOSTAGu dělit modely podle slovního poddruhu (druhá pozice české značky). Pak by dílčí modely byly menší a libsvm by třeba nespadlo. Ve skutečnosti budu asi muset zjemňovat jiným způsobem, protože právě u podstatných jmen žádné zvláštní lení na poddruhy neexistujeMohly by ale pomoct pády. +
- +
-==== Javová implementace libsvm ==== +
- +
-edpokládá se, že vyžaduje více času a paměti. Podle dokumentace může dojít k&nbsp;drobným odchylkám v&nbsp;úspěšnosti způsobeným odlišným zpracováním racionálních čísel.+
  
 | N | Úloha | Délka trénování | Délka parsingu | Rychlost parsingu | Úspěšnost | Datum | | N | Úloha | Délka trénování | Délka parsingu | Rychlost parsingu | Úspěšnost | Datum |
Line 125: Line 63:
 | 60000 | 1035254 | 7 dní 4:55 h | 34374 s = 9:33 h | 1 věta / 3,71 s | 85,80 % | 9.-17.4.2010 | | 60000 | 1035254 | 7 dní 4:55 h | 34374 s = 9:33 h | 1 věta / 3,71 s | 85,80 % | 9.-17.4.2010 |
 | 65000 | 1035255 | 5 dní 21:01 h | 31378 s = 8:43 h | 1 věta / 3,38 s | 85,96 % | 9.-15.4.2010 | | 65000 | 1035255 | 5 dní 21:01 h | 31378 s = 8:43 h | 1 věta / 3,38 s | 85,96 % | 9.-15.4.2010 |
-full | 1177906 | | | | | 27.4.2010 |+68563 | 1177906, 1305554 10 dní 4:40 h 46999 s = 13:03 h 1 věta / 5,07 s **86,08 %** | 27.4.-14.5.2010 |
  
-==== Trénovací data rozsekaná na pětitisícové úseky ====+===== Trénování větších modelů s céčkovou implementací libsvm padá =====
  
-| N | Úloha | Délka trénování | Délka parsingu | Rychlost parsingu | Úspěšnost | Poznámka | +//Malt Parser 1.3 jsem nedokázal použít s céčkovou implementací libsvm, která má být sice rychlejší, ale mně náhodně padala. Postupně jsem od ní zcela upustil a používám pomalejšíale bezpečnější Javovou implementaci. Přesto tady zatím nechávám tuhle kapitoluprotože odkrývá některé detaily o Malt Parseru (které by snad mohly platit i v současné verzi).//
-| 00000-04999 | 1021425 | | | | 76,65 % | | +
-| 05000-09999 | 1021426 | | | | 76,99 % | | +
-| 10000-14999 | 1021427 | | | | 76,47 % | | +
-| 15000-19999 | 1021428 | | | | 76,72 % | | +
-| 20000-24999 | 1021429 | | | | 76,72 % | | +
-| 25000-29999 | 1021430 | | | | 76,80 % | | +
-| 30000-34999 | 1021431 | | | | 76,87 % | | +
-| 35000-39999 | 1021432 | | | | 76,94 % | | +
-| 40000-44999 | 1021433 | | | | 76,72 % | | +
-| 45000-49999 | 1021434 | | | | 76,98 % | | +
-| 50000-54999 | 1021435 | | | | 76,69 % | | +
-| 55000-59999 | 1021436 | | | | 76,96 % | | +
-| 60000-64999 | 1021437 | | | | 76,81 % | | +
-| 65000-68562 | 1021438 | | | | 75,86 % | |+
  
-Všechny díly se nakonec podařilo použítčímž jsme definitivně vyvrátiliže by v&nbsp;trénovacích datech byla jedna nebo více vět, na kterých parser padá. Padání bylo asi opravdu způsobeno velikostí dílčích modelů v&nbsp;konkrétních případech.+Chybu hlásí ''sdm0.004.libsvm.mod''což je dílčí model pro hodnotu ''CPOSTAG'' číslo 4. Značky jsou číslovány podle pořadív&nbsp;jakém se v&nbsp;trénovacích datech objevily. Pokud tedy všechny podmnožiny trénovacích datkteré zkouším, začínají na začátku trénovacích dat, mají číslování značek stejné. Číslování je také možné ověřit tak, že rozbalíme model, vznikne stejnojmenná složka, v&nbsp;ní se pak podíváme do souboru ''symboltables.sym'' na část ''CPOSTAG'':
  
-Zarážející je ale úspěšnostPřinejmenším pro první pětitisícový úsek měla být s&nbsp;céčkovým libsvm 80&nbsp;%, tak jaktože jsme teď vždy naměřili pod 77&nbsp;%?+<code>java -jar ~/nastroje/parsery/malt-1.3/malt.jar -c model -unpack 
 +cd model 
 +less symboltables.sym</code>
  
-=== Oprava 6.4.2010 ===+Až na jednu výjimku trénování spadlo vždy při budování ''sdm0.004.libsvm.mod'' a vždy na větších trénovacích datech. Tento model patří podstatným jménům (přesněji: situacím, kdy na vrcholu zásobníku leží podstatné jméno). Tento model, resp. jeho vstupní data, jsou také zřejmě vždy největší. Není sice asi problém s&nbsp;dostupností operační paměti (''svm-train'' spotřebovává řádově stovky megabajtů, přitom má k dispozici desítky gigabajtů), ale vnitřní struktury libsvm asi na tak velká data nejsou připraveny.
  
-Předcházející pokusy s&nbsp;javovou implementací byly omylem spuštěny s&nbsp;výchozí, nikoli s&nbsp;Marcovou definicí rysů, což by mohlo vysvětlovat tu nižší úspěšnostNyní tedy druhý pokus:+Joakim navrhuje, abychom zkusili dělení zjemnit, např. místo CPOSTAGu dělit modely podle slovního poddruhu (druhá pozice české značky). Pak by dílčí modely byly menší a libsvm by třeba nespadlo. Ve skutečnosti budu asi muset zjemňovat jiným způsobemprotože právě u podstatných jmen žádné zvláštní dělení na poddruhy neexistuje. Mohly by ale pomoct pády.
  
-| N | Úloha | Délka trénování | Délka parsingu | Rychlost parsingu | Úspěšnost | Poznámka | +===== Splitting trick podle slovního poddruhujlibsvm =====
-| 00000-04999 | 1032102 | | | | | Nevysvětlitelná náhlá smrt během trénování. | +
-| 05000-09999 | 1032103 | 24:24 min | | | 80,59 % | | +
-| 10000-14999 | 1032104 | 31:56 min | | | 80,23 % | | +
-| 15000-19999 | 1032116 | 30:27 min | | | 80,52 % | | +
-| 20000-24999 | 1032106 | 21:35 min | | | 80,45 % | | +
-| 25000-29999 | 1032107 | | | | | Nevysvětlitelná náhlá smrt během trénování. | +
-| 30000-34999 | 1032108 | 28:30 min | | | 80,48 % | | +
-| 35000-39999 | 1032109 | | | | | Nevysvětlitelná náhlá smrt během trénování. | +
-| 40000-44999 | 1032110 | 19:17 min | | | 80,51 % | | +
-| 45000-49999 | 1032111 | 22:54 min | | | 80,62 % | | +
-| 50000-54999 | 1032112 | 22:31 min | | | 80,58 % | | +
-| 55000-59999 | 1032113 | | | | | Nevysvětlitelná náhlá smrt během trénování. | +
-| 60000-64999 | 1032114 | | | | | Nevysvětlitelná náhlá smrt během trénování. | +
-| 65000-68562 | 1032115 | 12:43 min | | | 79,69 % | |+
  
-==== Splitting trick podle slovního poddruhujlibsvm ====+Snižuje časovou náročnostzanedbatelně snižuje i úspěšnost.
  
 | N | Úloha | Délka trénování | Délka parsingu | Rychlost parsingu | Úspěšnost | Datum | | N | Úloha | Délka trénování | Délka parsingu | Rychlost parsingu | Úspěšnost | Datum |
Line 176: Line 88:
 | 5000 | 1177864 | 42:28 min | 3282 s = 54:42 min | 1 věta / 0,35 s | 79,86 % | 27.4.2010 | | 5000 | 1177864 | 42:28 min | 3282 s = 54:42 min | 1 věta / 0,35 s | 79,86 % | 27.4.2010 |
 | 10000 | 1177866 | 2:50 h | 5863 s = 1:38 h | 1 věta / 0,63 s | 81,63 % | 27.4.2010 | | 10000 | 1177866 | 2:50 h | 5863 s = 1:38 h | 1 věta / 0,63 s | 81,63 % | 27.4.2010 |
-| 20000 | 1177867 | | | | | 27.4.2010 | +| 20000 | 1177867 | 15:52 h 13877 s = 3:51 h 1 věta / 1,50 s 83,28 % | 27.-28.4.2010 | 
-| 25000 | 1177868 | | | | | 27.4.2010 | +| 25000 | 1177868 | 21:02 h 13345 s = 3:42 h 1 věta / 1,44 s 83,97 % | 27.-28.4.2010 | 
-| 30000 | 1177870 | | | | | 27.4.2010 | +| 30000 | 1177870 | 30:36 h 15689 s = 4:21 h 1 věta / 1,69 s 84,23 % | 27.-28.4.2010 | 
-| 35000 | 1177871 | | | | | 27.4.2010 | +| 35000 | 1177871 | 39:04 h | | | | 27.4.2010 | Parsing selhal. 
-| 40000 | 1177872 | | | | | 27.4.2010 | +| 40000 | 1177872 | 2 dny 8 h 19298 s = 5:22 h 1 věta / 2,08 s 84,92 % | 27.-30.4.2010 | 
-| 45000 | 1177873 | | | | | 27.4.2010 | +| 45000 | 1177873 | 2 dny 20 h 21907 s = 6:05 h 1 věta / 2,36 s 85,18 % | 27.-30.4.2010 | 
-| 50000 | 1177875 | | | | | 27.4.2010 | +| 50000 | 1177875 | 3 dny 14 h 22805 s = 6:20 h 1 věta / 2,46 s 85,37 % | 27.4.-1.5.2010 | 
-| 55000 | 1177876 | | | | | 27.4.2010 | +| 55000 | 1177876 | 5 dní 32512 s = 9:02 h 1 věta / 3,51 s 85,57 % | 27.4.-2.5.2010 | 
-| 60000 | 1177877 | | | | | 27.4.2010 | +| 60000 | 1177877 | 5 dní 20 h 27429 s = 7:37 h 1 věta / 2,96 s 85,70 % | 27.4.-3.5.2010 | 
-| 65000 | 1177878 | | | | | 27.4.2010 | +| 65000 | 1177878 | 6 dní 4 h 28112 s = 7:48 h 1 věta / 3,03 s 85,91 % | 27.4.-3.5.2010 | 
-| full | 1177879 | | | | | 27.4.2010 |+| full | 1177879 | 8 dní 7 h 38957 s = 10:49 h 1 věta / 4,20 s 86,02 % | 27.4.-6.5.2010 |
  
-==== Splitting trick podle slovního poddruhuclibsvm ====+===== Stackeagerjava libsvm, švédské rysy =====
  
-| N | Úloha | Délka trénování | Délka parsingu | Rychlost parsingu | Úspěšnost | Datum | +| N | Úloha | Délka trénování | Délka parsingu | Rychlost parsingu | Úspěšnost | Datum | Poznámka 
-| 1000 | 1177881 42 s 939 s = 15:38 min | 1 věta / 0,10 s | 73,81 % | 27.4.2010 | +| 1000 | 1473892 2:38 min 1283 s = 21 min | 1 věta / 0,14 s | 74,50 % | 2.6.2010 
-| 2000 | 1177882 2:31 min | 1659 s = 27:39 min | 1 věta / 0,18 s | 76,98 % | 27.4.2010 | +| 2000 | 1473932 7:45 min | 1891 s = 32 min | 1 věta / 0,20 s | 77,47 % | 2.6.2010 
-| 5000 | 1177883 17:52 min | 3324 s = 55:23 min | 1 věta / 0,36 s | 79,86 % | 27.4.2010 | +| 5000 | 1473933 49:08 min | 4178 s = 1:10 h | 1 věta / 0,45 s | 79,98 % | 2.6.2010 
-| 10000 | 1177884 1:15 h | 5966 s = 1:39 h | 1 věta / 0,64 s | 81,63 % | 27.4.2010 | +| 10000 | 1473934 3:33 h | 7534 s = 2:06 h | 1 věta / 0,81 s | 81,93 % | 2.6.2010 
-| 20000 | 1177901 náhlá smrt 1177885 | | | | 27.4.2010 | +| 20000 | 1473956 18:09 h 14095 s = 3:55 h 1 věta / 1,52 s 83,47 % 2.-3.6.2010 
-| 25000 | 1177886 | | | | | 27.4.2010 | +| 25000 | 1473957 26:12 h 17299 s = 4:48 h 1 věta / 1,87 s 84,01 % 2.-3.6.2010 
-| 30000 | 1177887 | | | | | 27.4.2010 | +| 30000 | 1473958 2 dny 25161 s = 6:59 h 1 věta / 2,71 s 84,43 % 2.-4.6.2010 
-| 35000 | 1177888 | | | | | 27.4.2010 | +| 35000 | 1473982 42:40 h 18856 s = 5:14 h 1 věta / 2,03 s 84,74 % 2.-4.6.2010 
-| 40000 | 1177902 náhlá smrt 1177889 | | | | 27.4.2010 | +| 40000 | 1473983 3 dny 18 h 32172 s = 8:56 h 1 věta / 3,47 s 85,08 % 2.-6.6.2010 
-45000 1177890 | | | | 27.4.2010 | +50000 1474005 | 4 dny 19 h 29638 s = 8:14 h 1 věta / 3,20 s 85,26 % 2.-7.6.2010 
-50000 | 1177904 náhlá smrt 1177891 i 1177904vzdávám | | | 27.4.2010 | +| 55000 | 1474009 7 dní 17 h 41959 s = 11:39 h 1 věta / 4,53 s 85,51 % 2.-10.6.2010 
-| 55000 | 1177892 | | | | | 27.4.2010 | +| 60000 | 1474010 9 dní 8 h 43088 s = 11:58 h 1 věta / 4,65 s 85,65 % 2.-12.6.2010 
-| 60000 | 1177893 náhlá smrt 1177893 | | | | 27.4.2010 | +| 65000 | 1474011 7 dní 14 h 37991 s = 10:33 h 1 věta / 4,10 s 85,81 % 2.-10.6.2010 
-| 65000 | 1177894 náhlá smrt 1177894 | | | | 27.4.2010 | +| full | 1474032 8 dní 6 h 40110 s = 11:09 h 1 věta / 4,33 s 85,94 % 2.-11.6.2010 |
-| full | 1177895 náhlá smrt 1177895 | | | | 27.4.2010 |+
  
-==== Co dál? ====+===== Stackproj, java libsvm, švédské rysy ===== 
 + 
 +| N | Úloha | Délka trénování | Délka parsingu | Rychlost parsingu | Úspěšnost | Datum | Poznámka | 
 +| 1000 | 1474105 | 2:46 min | | | | 7.6.2010 | Parsing nedoběhl ("The symbol code '-1' cannot be found in the symbol table.") | 
 +| 2000 | 1474106 | 6:53 min | 1810 s = 30 min | 1 věta / 0,19 s | 74,74 % | 7.6.2010 | | 
 +| 5000 | 1474107 | 51:45 min | 3723 s = 1:02 h | 1 věta / 0,40 s | 76,84 % | 7.6.2010 | | 
 +| 10000 | 1474108 | 3:38 h | 6934 s = 1:55 h | 1 věta / 0,75 s | 78,50 % | 7.6.2010 | | 
 +| 20000 | 1474109 | 17:03 h | 13256 s = 3:41 h | 1 věta / 1,43 s | 79,57 % | 7.-8.6.2010 | | 
 +| 25000 | 1474110 | 29:14 h | 15764 s = 4:23 h | 1 věta / 1,70 s | 80,23 % | 7.-8.6.2010 | | 
 +| 30000 | 1474111 | 36:55 h | 18845 s = 5:14 h | 1 věta / 2,03 s | 80,50 % | 7.-9.6.2010 | | 
 +| 35000 | 1474112 | 2 dny 4 h | 20638 s = 5:44 h | 1 věta / 2,23 s | 80,80 % | 7.-9.6.2010 | | 
 +| 40000 | 1474113 | 3 dny 11 h | 30127 s = 8:22 h | 1 věta / 3,25 s | 81,01 % | 7.-11.6.2010 | | 
 +| 45000 | 1474114 | 4 dny 17 h | 33036 s = 9:10 h | 1 věta / 3,56 s | 81,04 % | 7.-12.6.2010 | | 
 +| 50000 | 1474115 | 5 dní 4 h | 35954 s = 9:59 h | 1 věta / 3,88 s | 81,35 % | 7.-13.6.2010 | | 
 +| 55000 | 1474116 | 4 dny 23 h | 30700 s = 8:32 h | 1 věta / 3,31 s | 81,48 % | 7.-12.6.2010 | | 
 +| 60000 | 1474117 | 6 dní 9 h | 32758 s = 9:06 h | 1 věta / 3,53 s | 81,58 % | 7.-14.6.2010 | | 
 +| 65000 | 1474118 | 9 dní 20 h | 44870 s = 12:28 h | 1 věta / 4,84 s | 81,70 % | 7.-17.6.2010 | | 
 +| full | 1474119 | 7 dní 11 h | 36260 s = 10:04 h | 1 věta / 3,91 s | 81,88 % | 7.-15.6.2010 | | 
 + 
 +===== Covproj / covnonproj / nivrestandard / nivreeager, java libsvm, švédské rysy ===== 
 + 
 +Všechny trénovací procesy hlásí "The function cannot be initialized." Mohlo by to být tím, že Marcova definice rysů, kterou se pokouším použít, byla původně určena pro algoritmus ''stacklazy''. Takže se třeba snaží dívat na zásobník, se kterým Covingtonův algoritmus vůbec nepracuje? Žádnou změnou na clusteru ta chyba totiž není, trénink ''stacklazy'' se rozeběhne bez problémů stejně jako dřív.
  
-  * Ještě pustit javovské ''libsvm'' a uppsalské dělení (CPOSTAG) na celý treebank. Zatím jsem to udělal nejvýše pro prvních 65000 vět, ale treebank jich má přes 68000. 
-  * Navrhnout jemnější dělení modelů ''libsvm'', aby modely 003 a 004 nebyly tak velké. Např. přidat slovní poddruh a pád. 
-  * Rozsekat trénovací data na 14 pětitisícových kusů a s&nbsp;každým z&nbsp;nich pustit trénink a parsing zvlášť. Spadnou některé? A mimochodem, jakou úspěšnost by dalo hlasování takto natrénovaných kusů? 
-  * Zkusit ''liblinear'' místo ''libsvm''. 
-  * Odladit ''train.pl'', aby se výsledný soubor ''.mco'' dal rozbalovat. Možná mu vadí pouze ".mco" u volby ''-c''. 
-  * Jestli nakonec nějak prorazím, bude potřeba opět učesat obalovací skripty. Mj. jsem přišel na to, že ve většině svých skriptů používám jako dočasný adresář ''/tmp'' místo Milanem důrazně doporučeného ''/mnt/h/tmp''. Např. na tauri10 jsem tak počmáral 4 GB a proces skončil, protože příslušný svazek byl plný. Tohle by se mj. mělo opravit i u skriptů pro Joshuu a dalších. Jinak jsem taky mohutně čachroval s žádostí o příděl paměti na clusteru (týká se i skriptu ''qsub.csh''), s konfigurací Maltu atd. 
-  * Vyhodnotit to ještě i na e-testu a připsat to na stránku o českém parsingu. 

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