2009-06-02 14 views
5

Piszę historię rozdań pokera od zeszłego roku i nauczyłem się całkiem sporo o parsowaniu w ogóle.Co to są egzotyczne techniki analizowania?

Zaczęliśmy od wyrażeń regularnych, ale szybko zdaliśmy sobie sprawę, że nie skalowalibyśmy się łatwo. Pominęliśmy języki z ruby ​​do C++ i wreszcie doszliśmy do wniosku, że to algorytm musiał się zmienić.

Podnieśliśmy Boost :: Spirit i obserwowaliśmy, jak nasza prędkość gwałtownie rośnie w zamówieniach o ponad 10 razy większych od naszej pierwotnej prędkości. Następnie przeskoczyliśmy do java i obecnie używamy antlr do tworzenia gramatyk dla każdej witryny. Jest to zdecydowanie najszybsza metoda i jest bardzo dokładna, co jest miłe, ponieważ dokładnie wiesz, gdzie się znajdujesz pod względem "kompletnej" gramatyki. Niestety, spędziłem niesamowitą ilość czasu pracując z tymi gramatykami - pracują całkiem nieźle, ale jeszcze nie perfekcyjnie.

W każdym razie, wystarczy z tłem do danego pytania - czy istnieją jakieś "egzotyczne" lub mniej znane techniki do analizowania, których nie znam? Wiem tylko o leksykowaniu/analizie gramatyki i innej gorszej metodzie regex/loop.

Dla tych z was, którzy nie znają historii rozdań pokera, opublikuję jeden, abyście mogli powiedzieć, jaka jest struktura.

Full Tilt Poker Game #12037626529: Table durrrr (heads up, deep) - $500/$1000 - 
Pot Limit Omaha Hi - 2:00:48 ET - 2009/05/05 
Seat 1: durrrr ($196,456.50) 
Seat 2: Gus Hansen ($65,499) 
durrrr posts the small blind of $500 
Gus Hansen posts the big blind of $1,000 
The button is in seat #1 
*** HOLE CARDS *** 
durrrr raises to $3,000 
Gus Hansen raises to $9,000 
durrrr calls $6,000 
*** FLOP *** [3d 4d 7d] 
Gus Hansen has 15 seconds left to act 
Gus Hansen checks 
durrrr checks 
*** TURN *** [3d 4d 7d] [Jh] 
Gus Hansen checks 
durrrr checks 
*** RIVER *** [3d 4d 7d Jh] [Ah] 
Gus Hansen has 15 seconds left to act 
Gus Hansen checks 
durrrr has 15 seconds left to act 
123stayfree (Observer): GUS I NOW BRING U LUCK 
durrrr bets $7,600 
Gus Hansen has 15 seconds left to act 
Gus Hansen has requested TIME 
Hernandez777 (Observer): Gus has the super-duper nuts 
Gus Hansen calls $7,600 
Podobed45 (Observer): fluuuuuuuuuush 
*** SHOW DOWN *** 
durrrr shows [Kc 3s Qd As] two pair, Aces and Threes 
Gus Hansen mucks 
durrrr wins the pot ($33,199.50) with two pair, Aces and Threes 
*** SUMMARY *** 
Total pot $33,200 | Rake $0.50 
Board: [3d 4d 7d Jh Ah] 
Seat 1: durrrr (small blind) collected ($33,199.50) 
Seat 2: Gus Hansen (big blind) mucked 

Jestem świadom innych metod zbierania informacji (takich jak ekran skrobaniu i zastrzyk DLL), ale konieczność przekształcenia historii dłoni w danych strukturalnych nadal istnieje więc szukam tylko w metody pobierające informacje, takie jak regex/gramatyki ...

Myślę, że jeśli nie znajdę czegoś, co zamierzam przerobić nasze gramatyki za pomocą ocamllex/ocamlyacc.

aktualizacja

FYI: regexen prędkość wynosiła ~ 60 rąk/s, podczas gdy gramatyki były przetwarzania 600 + rąk/s ... cała ręka jest przekształcona xml po danych jest wszystko załatwione .. potrzeba 20-30 regularnych wyrażeń (w ostatniej chwili) dla KAŻDEJ strony, którą chcesz przeanalizować ... każda strona po stronie gramatyki ma własną gramatykę z nieprzyzwoitymi ilościami reguł leksera/analizatora składni (ale wciąż ma mniejszy rozmiar kodu)

Mam książkę smoka i czytałem ją - co odrzuciło moje zainteresowanie korzystaniem z ocamllex/ocamlyacc .... prędkość to nazwa gry tutaj ..

+2

Dowiedziałeś się całkiem "interesu" - fajnie. – harpo

+0

Istnieje kilka naprawdę wspaniałych i dzikich pomysłów w książkach kompilatorów, które pojawiły się zanim rekursywne zejście ugruntowało swoją pozycję. Miałem kiedyś jedną z tych książek. Był to zbiór artykułów na temat projektowania kompilatorów z lat 70.Szkoda, że ​​wciąż to mam. – Nosredna

+0

Och, inteligentny bot poker, który potrafi skanować historię i podejmować inteligentne decyzje w oparciu o jej odkrycia? Miły! –

Odpowiedz

3

Jeśli chcesz zmaksymalizować prędkość, lepiej użyć OcamlYacc/FsYacc zamiast ANTLR. OcamlYacc tworzy parsery LL (1), które zazwyczaj mają lepszą wydajność niż parsery LL (*) w stylu ANTLR (ktoś może mnie poprawić, jeśli się mylę). [Edytuj, aby dodać:] Wygląda na to, że ktoś mnie poprawił: OCamlYacc tworzy parsery LALR (1). Nie mogę powiedzieć z całkowitą pewnością, czy parsery OcamlYacc są szybsze niż parsery ANTLR.

OCaml/F # są bardzo dobrymi językami do budowania DSL, i moim zdaniem są dużo bardziej odpowiednie do tej pracy niż Java, głównie dlatego, że jest to absurdalnie łatwe do stworzenia i przejścia AST reprezentowanego jako struktura danych związku. Polecam this tutorial, który pokazuje, jak parsować SQL w F #.

+0

Nie mam dużo exp. z różnicą. parsery tam, ale wszystko, co przeczytałem, mówiło, że złożoność czasu/przestrzeni jest na korzyść LL (1), a także przypadkowo rozwiązuje kilka problemów w LL (k)/LL (*) – eyberg

+0

To jest niepoprawne. ocamlyacc, jak yacc i bizon, produkuje LALR (1), a nie LL (1). –

+0

Poszukuję parsera SQL i lubię F #, więc +1 –

1

Recursive Descent Parsing może pracować dla Ciebie. Jest bardzo konfigurowalny. Może być nieco wolniejszy niż yacc/antlr, ale może być wystarczająco szybki. Podstawowa idea: kodujesz każdą regułę gramatyczną jako funkcję.

+0

ANTLR generuje parser rekursywny (jak większość generatorów parserów opartych na LL) –

2

Musisz zadać sobie pytanie, czy to, co naprawdę chcesz robić to bawić z parserami (wprawdzie zabawne, i co ja preferuję) lub jeśli chcesz faktycznie wykonać pracę na swoim bocie pokerowym. W większości przypadków egzotyczne techniki przetwarzania są przesadzone, jeśli chodzi o to, czego potrzebujesz. Wystarczy wybrać szybki język z prostymi, łatwymi w użyciu analizatorami. Prawdopodobnie powinieneś być w stanie przetworzyć 10k rąk na sekundę z prostym C + flex. Lub ocamllex + ocamlyacc powinno wystarczyć. Jeśli musisz wymyślić kod, myślę, że robisz coś nie tak. Opóźnienie sieci powinno być prawdziwym wąskim gardłem, a nie prędkością przetwarzania. Jakiego rodzaju maszyna to uruchamiasz?

Inną alternatywą jest użycie generatora analizatora składni do automatycznego generowania tabeli analizowania, a następnie ręczna optymalizacja lub ręczna optymalizacja z NFA (prawdopodobnie nie zaoszczędzisz dużo, a kompromis w czasie programisty prawdopodobnie nie jest warty to). Rozpatrywanie kombinatorów będzie prawdopodobnie wolniejsze.

Średnio dla danej gramatyki o równoważnej mocy LL będzie wolniejsza niż LALR. W szczególności, jeśli dłonie pokera są w rzeczywistości parsowane przez parser LALR, to bison/byacc + flex pokona wszystkie ręce ANTLR za każdym razem. Osobiście jestem całkiem zadowolony z menhiru, chociaż jest to szaleńcza suka, która pracuje z godi + ocamlbuild.

--Nico