Monday, October 26, 2015

REST API a Python

Jedna z mojich dlžôb bolo vytvorenie REST rozhrania k morfologickému analyzátoru. Rozhranie pre python ma trápilo viac (github/pymajka), takže malo výrazne vyššiu prioritu. Vytvoriť REST by preto mala byť len rutina, takže ma to ani príliš nelákalo. Požiadavky na výkon som nemal, akurát som nechcel žiaden veľký framework.

Prvý pokus bol s web.py, tutoriál funguje úplne krásne. Prvé API postavené za pár minút, ale vyskytol sa dosť divný problém. Spolupráca s modulom pymajka fungovala krásne z príkazového riadku, ale cez HTTP to končilo s core dump. Riešil som a riešil, ale nepodarilo sa. Padalo to na mieste, kde céčková knižnica mala všetky parametre :/

Po týždni som sa dostal k druhému pokusu. Tentokrát som skúsil bottle a ten funguje od začiatku ako má. 

Tuesday, July 14, 2015

Prečítal som: Python Testing - Beginner's Guide

Kniha nebola písaná pre niekoho ako som ja, čo som ale mohol čakať už podľa
názvu. Napriek tomu som sa ňu tešil, pretože masívnejšie využitie testovanie
ma ešte len čaká. Kniha od čitateľa nečaká veľa, ale jednoznačne sa hodí mať
nejaký základný prehľad o Pythone. Na knihu pre začiatočníkov sú však podľa
mňa priložené zdrojáky príliš dlhé (a viac-menej nudné). Aj preto sa mi
podarilo prečítať/prebehnúť celú knihu za jedno poobedie.

Kapitoly sa postupne zameriavajú na využitie Doctest, unittest, nosetests a
mock. Práve ten mock ma zaujímal najviac, ale to vysvetlenie mi prišlo také
nijaké a asi by som z toho pochopil len tú základnú myšlienku, ale na
samostný spôsob ako to použiť by som potreboval iný materiál. A to aj
napriek tomu, že príkladov je tam dostatok.

Záver? Nekupovať.

Tuesday, June 30, 2015

Záverečné práce za posledný semester

Dnes sa odovzdali posledné bakalárske práce tohoto semestra. S trochou šťastia to bol môj posledný semester s veľkým počtom prác. Oproti minulým semestrom som si síce pomohol (vďaka Adam :)), ale stále ich bolo tesne pod dvadsať. Jedna práca neprešla, pár ich prešlo len tesne a tri sú nominované na cenu dekana. Pretože sa nájdu aj zaujímavé práce u niekoho iného, tak tu je zoznam prác z FI, ktoré stoja za to.

Iné, ale podľa názvu ma zaujali a po prečítaní si ich chcem pamätať:
  • Martin Otáhal - Analýza a návrh architektúry v MapReduce
    • Po zbežnom prečítaní to vyzerá ako rozumný návod na pochopenie MapReduce a jeho inštaláciu/konfiguráciu.
  • Daniela Plachtová - Umelá inteligencia do OpenTTD
    • Umelá inteligencia pre spoločnosť, ktorá prepravuje tovar/osoby vlakmi implementovaná do openTTD. Pri snahe o implementáciu UI do nejakej našej hry by to mohla byť dobrá inšpirácia. 
  • Michal Hlaváč - System for Recognizing Textual Entailment utilizing Expert Knowledge
    • Hoci posudky nie sú nič extra, tak pretože o téme prakticky nič neviem, dostáva sa do zoznamu na čítanie. A áno, nefunguje to.
  •  Petr Machovec - Automatická sumarizace textu

Sunday, March 1, 2015

Ako sa hodnotí bakalárska/diplomová práca? [0.4]

Tento príspevok bude zameraný na kontrolu záverečných prác z informatiky (na univerzite nezáleží), pravidlá sú vlastne rovnaké pre študenta, vedúceho aj oponenta. Pravidlá sú zoradené chronologicky podľa toho, kedy som na daný problém narazil.

  1. Vedúci/oponent vie často o téme viac než popisuje samotná práca. Preto je dôležité, aby úroveň práca bola taká, že ju pochopí aj osoba (absolvent informatiky), ktorý o téme nič nevie. Takže, ak použijeme regulárne výrazy, tak nevysvetľujeme. V prípade termínov ako bundling, alebo Context Dependency Injection je vysvetlenie skutočne nutné, potrebujeme preto krátky (adekvátny práci) popis v texte a odkaz na zdroj, kde sa čitateľ dozvie viac.
  2. Prácu by okrem autora, vedúceho a oponenta mali pochopiť aj iní. Úvod by mal pochopiť každý VŠ vzdelaný človek, zbytok práce absolvent informatiky. 
  3. Odkazovanie do bibliografie je tiež oriešok. Typicky a obvykle správne sa zadáva:
    • priamo do textu -> len odkazy do literatúry (nie URL)
    • pod čiaru -> typicky URL na webové stránky projektov
  4. Pri položkách v bibliografii je potrebné dodržiavať "normu", ktorá sa líši fakultu od fakulty. Problém nastáva pri webových stránkach, kde je okrem URL potrebné zadať aj dátum čerpania.
  5. Ak je práca zameraná na tému, kde sa dá očakávať, že to bolo riešené, tak je potrebné overiť, že sa na rozumne aktuálne práce odkazuje. Odborné články nájdete na scholar.google.com, ktorý vytvorí aj bibliografický záznam. Robí to automaticky, preto je na záver to potrebné ručne zjednotiť, aby to vyzeralo správne (pozor na diakritiku) a rovnako.
  6. Odkazy na blogy, diskusné fóra, ... sú často najlepší zdroj praktických znalostí. Na popisy algoritmov, informatiky, .. sú často vhodnejšie. odborné články a monografie. Wikipediu radšej nepoužívať vôbec.
  7. Ak sa preberá text/obrázok ako copy&paste (aj doslovný preklad), tak je nutné správne označiť zdroj. V prípade textu dať aj vizuálne najavo, že tento text je doslovná citácia. Inak sa to dá chápať ako plagiátorstvo.
  8. UML diagramy (a aj všetky ostatné obrázky) sú vítané, ale ak tam sú bezúčelne, tak to komisiu naštve viac ako by tam neboli.
  9. Ak zadanie explicitne menuje funkcionalitu, tak to práca musí splniť. Ak zadanie píše explicitne o vyhodnotení, testovaní, ... tak to práca tiež musí splniť. Ak sa to nedá, tak je potrebné vysvetliť a odôvodniť v texte, že to nie je reálna požiadavka. Obvykle je lepšie zmeniť včas oficiálne zadanie.
  10. Jazyk práce (čeština, slovenčina, angličtina) by mal byť dodržiavaný počas celej práce. Takže je potrebné používať aj príslušné odborné termíny a vyhnúť sa slovám ako debugovať, logovať. V prípade, že preklad neexistuje, tak si ho nemusíte vymýšlať. Ak očakávate, že tých nepreložiteľných termínov tam bude priveľa, tak to píšte rovno anglicky.
  11. Kvalita textu je z pohľadu univerzity aspoň rovnako dôležitá ako kvalita kódu aplikácie. Ak nemáte nikoho na kontrolu gramatiky, preklepov, predložiek tak ho za študentské ceny nájdete v ISe na inzercii.
  12. Väčšina záverečných prác nemá teoretickú časť (veta, hypotéza, dôkaz, ...), ale textovú časť a praktickú časť. Niektoré osoby sú na to (vcelku oprávnene) háklivé.
  13. Počet znakov záverečnej práce nie je univerzálne merítko. Ak by práca mala byť príliš dlhá, tak je vhodné vhodné časti (sady grafov, používateľský manuál) do príloh. 
  14. Po odovzdaní musí byť všetko v informačnom systéme. Github je fajn, ale aj tak to tam má byť nakopírované.
  15. Pre práce, kde sa niečo programuje odporúčam nasledujúcu štruktúru
    • Popis aktuálnych (podobných) riešení
    • Podrobná analýza problému
    • Návrh a implementácia
    • *Použité technológie -> ak ich zadanie explicitne zmieňuje, tak aj pred popis aktuálnych riešení, inak niekde k analýze/návrhu
    • Vyhodnotenie výsledkov 
  16. Ak vedúci uvidí prácu až tesne pred odovzdaním, tak času na opravy je už málo. A skoro určite to bude z posudku zrejmé. Komunikovať a posielať text je treba priebežne, netreba čakať na všetky kapitoly.
  17. Odovzdaný kód by mal mať:
    • dokumentáciu (API vždy, inak je to plus), ideálne podľa JavaDoc, PEP, ...
    • súbory by mali byť rozumne veľké (riadky, objekty, funkcie)
  18. Odovzdaný kód by nemal mať:
    • divné konštrukcie, magic numbers, ...
    • zakomentovaný kód bez jasnej dokumentácie
  19. Bonus: ako na obhajobu
    • Vybrať ruky z vačkov nohavíc
    • Hovoriť nahlas a pozerať sa na ľudí
    • Obrázok na slajde je plus
    • Na slajdoch by nemalo byť všetko + nečítať
    • Hodnotiť svoju prácu vecne a odborne

Monday, February 23, 2015

Prečítal som: Tajemství Sit'n'Go, Phil Shaw

Druhá z kníh za štyri eurá dopadla výrazne lepšie. Jedná sa síce o SnG, ktoré aktuálne nehrávam, ale prišli mi výborná :) Na rozdiel od predchádzajúcej knihy, kde sa hral poker vyslovene pasívne, sa tu hrá normálny poker. S ohľadom na charakteristiku SnG je to samozrejme od istej fázy len all-in/fold, ale kniha to podáva veľmi rozumne. Celá kniha je postavená na počítaní ICM a tom ako to dopadá podľa veľkosti blindov. Každej z častí sa venuje jedna kapitola, takže máme hru rannú, strednú, neskorú, troch hráčov a heads-up. Jasne, že to sú SnG, takže žetóny žiadne a pri 2-3 hráčov to už podľa mňa nie je poker, ktorý by som chcel hrávať. Na záver je zoznam kvízových hand (~100 strán), takže sa to dá celé vyskúšať aj bez peňazí. Ale tak 80-90% som dal správne po prečítaní knihy a len odhadometricky, takže to nie sú úplne hraničné situácie.

Kupovať.

Friday, February 6, 2015

Prečítal som: Poker jak si vydělat hraním No-limit Hold'em (cash game)

Pokrové knihy vidím málokedy v bežnom kníhkupectve, tak som sa neudržal a naposledy kúpil rovno dve v akcii za 4€. Kniha (2010, preklad 2013) možno kedysi mala nejaký zmysel, ale dnes fakt nie. Prevažná časť textu je zameraná na konzervatívneho hráča a čakanie na výborný setup. S AK sa limpuje z buttonu, situácie 80/20 sa neriešia all-inom, lebo by to mohlo súperovi dôjsť. Podľa mňa to tak nefunguje, teda minimálne na micro-stakes. A v tom je ďalší problém, kniha píše v podstate o živej hre (mid-stakes) a fakt neviem ako sa hrá na 10/20$ a nebude to vedieť ani väčšina čitateľov.

Nekupovať.

Thursday, January 15, 2015

Prečítal som: The Power Of Habit, Charles Duhigg

Konečne sa mi podarilo prečítať aj túto knihu. Medzi rozčítanými sa nachádzala asi od novembra, kedy som sa dostal do polovice.

Kniha sa zaoberá o tom ako vyzerajú naše zvyky (habit, tj. nie kultúrne zvyky), aký majú na náš vplyv a čo vďaka nim kto dokázal. Príklady sa mi veľmi páčili, to najlepšie na knihe je, že vlastne nie je prvoplánovo motivačná. Až v prílohe sa trochu rieši ako by mala vyzerať naša práca so zvykmi, ale ktoré zvyky sú vhodné a ktoré menej vôbec nerieši.

Asi najlepšia časť pre mňa bola tá, ktorá hovorila o trénerovi amerického futbalu a zmene tímu, tak aby pracovala automaticky (na základe zvyku). Zaujímavá perlička bola o gambleroch, ktorí pri takmer-výhre prežívajú podobné pocity akoby vyhrali a preto vydržia hrať dlhšie, o viac peňazí, ...

Sunday, January 4, 2015

Rešerš: Detekcia textov zo strojového prekladu

Bigger is better.

Pri získavaní najväčšieho (a ?najlepšieho) korpusu potrebujeme stiahnuť veľké množstvo textov z webu. Vzhľadom na ich povahu je potrebné takéto dáta vyčistiť od jasného bordelu, iných jazykov a odstrániť duplicity. V takýchto dátach však bude stále dosť textu, ktorý vznikol strojovým prekladom.

V týchto dát bude ešte dosť text, ktorý strojový preklad.

A takýto text chceme odstrániť, takže to je naša motivácia. Najskôr som objavil v czTenTen12 preklad wikipedie (Ludvík dodávka Beethoven), ale všetko ostatné je potrebné robiť automaticky.

Samozrejme, že sme problém najskôr riešili a až teraz hľadáme, kto to ako robil :)

Kurokawa et al.: "Automatic detection of translated text and its impact on machine translation", MT Summit, 2009

Z článku je pre nás dôležitá najmä jeho prvá časť, ktorá sa venuje detekcii prekladaného textu. Jedná sa o texty z Kanadského parlamentu (Canadian Hansard, 1996-2007), ktoré sú bilinguálne (anglicky/francúzsky), je ich veľa 4,5 milióna viet a 85K "odstavcov". Pre každý z textov máme naviac informáciu o tom, či sa jedná o preklad, alebo originál. Na rozdiel od nášho problému, tak pracujeme s kvalitnými textami na oboch stranách.

Klasifikácia prebiehala pomocou SVM na n-gramoch {1,..,5} a to s použitím word/lemma/POS, alebo len POS resp. mixed (významové slová sa nahradia POS, zbytok zostáva). Pri tejto klasifikácie sa podarilo získať ~90% na odstavcoch a ~77% na vetách. Pri využití POS/mixed to kleslo pri odstavcoch na ~85%. 

Pre nás nepoužiteľný, ale inak pekný výsledok sa dosiahol pri preklade, kde pri trénovacích dátach z jedného jazyka stačilo asi 1/5 textu na dosiahnutie rovnakého skóre. 

Somers et al.: "Detecting inappropriate use of free online machine-translation by language students", EAMT, 2006

Strojový preklad sa dá používať aj na písanie domácich úloh. Na úrovni A dostačuje a v Anglicku skončíte so známkou C. Študenti dostali za úlohu preložiť jeden text poctivo a druhý pomocou prekladača (Babelfish) a následne rýchlo opraviť najväčšie chyby. Texty boli vcelku krátke (ale už sa nájsť nedajú). 

Na porovnanie sa používali slová použité len raz (hapax legomena, singleton), dvakrát (dis legomena), n-gramy a aj BLEU, NIST. To bola výhoda toho, že máme k dispozícii aspoň nejaký správny preklad.

Aharoni et al.: "Automatic detection of Machine Translated text ...", ?aclweb?, ?2013?

Hlavnou myšlienkou tohto článku je, že presnosť detekcie strojového prekladu koreluje s kvalitou prekladu. A teda sa dá použiť na meranie kvality prekladu. Na rozdiel od NIST/BLEU nie je potrebné mať referenčný preklad, čo je dosť veľká výhoda.

Samotný test bol založený na preklade 20K viet pomocou Systranu, Google Translate a piatich komerčných prekladačoch. Binárne klasifikátory a SVM, nič špeciálne. Celé to funguje pekne až na frázové prekladače, ktoré rieši pridanie syntaktických klasifikátorov (parser Berkeley).

Carter, Inkpen: "Searching for poor quality machine translated text: ...", časopis Advances in Artificial Intelligence, 2012

Úplne rovnaká úloha ako máme my, akurát opäť na anglicky a francúzštine (oba smery). Bolo použité SVM a klasifikátory (unigramy, priemerná dĺžka tokenu a pomer POS/token). Rozdiel oproti iným článkom je použitie troch rozličných sád textov. Najkvalitnejšou je časť Canadian Hansard, nasledovaná vládnymi webmi a nakoniec štátnych webov regiónu Ontario. Webové dáta môžu obsahovať aj zopár dát, ktoré sú zle klasifikované - rozdiel oproti Hansard.

Dosiahnuté čísla (voči strojovému prekladu pomocou Bing) sú pre Hansard perfektné. F-score sa pre jednotlivé kategórie pohybuje medzi 0,966 a 0,980. Model natrénovaný na Hansarde dáva pre vládne weby F-score prevažne nad 0,9 s dvoma výnimkami. Tá hlavná je rozpoznávanie anglického prekladu na webe č.5 - F-score 0,298. Pre weby z Ontaria sú F-score 0,907 pre text písaný anglicky človekom a 0,755 pre francúzske. V tomto prípade, žiaden strojový preklad nebol klasifikovaný ako pravdivý.


Čísla naznačujú pretrénovanosť modelu, ale ten nebol nijako upravovaný. A klasifikátory sú len tie vyššie spomenuté.

Arase, Zhou: "Machine translation detection from monolingual web-text", ACL, 2013 [*asi najlepší článok]

Aj v paralelných korpus sa nachádzajú strojové preklady (až 15% japonských textov v jednom experimente). Navrhovaná metóda spočíva vo vyhľadávaní gappy-phrase a následne phrase-salad, ktorý je špecifický pre súčasný štatistický preklad. Jedná sa obvykle o frázy, ktoré obsahujú diery: "not only X but". SMT zvládnu úspešne preložiť prvú časť, ale s tou druhou majú problémy.

Dám si nielen veľké chladené pivo ale aj hranolky. 
I'll not only large but also chilled beer fries

Dám si nielen pivo ale aj hranolky.
I'll not only beer but also fries.
Na príklade je vidno, že sa mi to nepodarilo úplne nájsť. Vidno, že Google sa dokáže naučiť frázu, ale aplikuje ju dosť zvláštne. Ak by tam chýbalo 'but also' tak je to frázový šalát. Pri automatickej extrakcii takýchto fráz nájdeme aj také, ktoré pre človeka nedávajú zmysel: "after X afther the", "no X not".

Pri vyhodnocovaní sa snažíme nájsť práve tie porušenia, šalát. Pri pekných vetách dosiahli presnosť 95,8% (ale japončina), ľudia sa zhodli na 88,2%. Na webových stránkach bez preprocessingu to je 80,6% na vete.

Koppel, Ordan: "Translationese and its dialects", ACL, 2011

Mimo náš problém? Rozpoznávanie zdrojového jazyka prekladu. Využitých bolo päť jazykov z Europarl (IT, FR, ES, DE, FI a cieľovej angličtiny). Rozpoznávanie bolo po chunkoch, ktoré mali ~2K slov.  Rozpoznávanie bolo úspešné na 92,7% čo sa mi viac než dosť, keďže ja by som to nezvládol :)

Pre ďalšie veci v rámci prekladu medzi jazykmi je dobré pozrieť translationese, ktoré sú práve tie zvlášnosti pri preklade a sú študované prekladateľmi a lingvistami.