On Monday, April 4, 2016 at 2:05:24 PM UTC+2, mk wrote:
> Próbuję zaimplementować możliwie efektywnie algorytm rozwiązujący pewien
> problem sprowadzający się do gry o sumie stałej pomiędzy dwoma
> przeciwnikami.
>
> W pierwszym kroku zaimplementowałem algorytm min-max (w postaci negamax).
>
> W moim problemie do danego stanu gry (transpozycji) można dojść czasami
> na wiele różnych sposobów więc by przyśpieszyć działanie algorytmu
> zastosowałem "memoryzację" czyli zapamiętuję już przeanalizowane stany
> gry (transpozycje) i wykorzystuję taki wpis jeśli ponownie natrafię na
> wcześniej przeanalizowaną transpozycję. Obliczenia znacząco
> przyśpieszyły, wyniki zgodne, jak dotąd dobrze...
>
> Obok, wzbogaciłem też algorytm negamax (bez memoryzacji) o alpha-beta
> prunning. No i też OK: obliczenia przyśpieszyły, wyniki zgodne, jak
> dotąd dobrze...
>
> Dalej, chcę połączyć alpha-beta prunning z memoryzacją... Zaświtało mi w
> głowie, że to będzie bardziej skomplikowane niż na początku by się mogło
> wydawać... ale od czego Internet, poszukajmy jak zrobili to inni i
> natrafiłem na artykuł Wikipedii:
> https://en.wikipedia.org/wiki/Negamax#Negamax_with_a
lpha_beta_pruning_and_transposition_tables
>
> Zaimplementowałem u siebie algorytm przedstawiony w Wikipedii i niestety
> zacząłem otrzymywać wyniki niezgodne z trzema uprzednio przedstawionymi
> metodami.

Też z tym miałem problemy. Nie pamiętam już czy dla wszystkich pozycji
otrzymałem ten sam wynik. U mnie czasami wersja z błędem grała lepiej, więc
się aż tak bardzo nie przejmowałem.

Najpierw zwróć uwagę na to co jest niezgodne: najlepszy ruch, wartość dla najlepszego
ruchu, czy jeszcze coś innego?

Jak odzyskujesz układy z tablicy transpozycji? Czy wtedy gdy depth>=curr_depth,
czy wtedy gdy depgh==curr_depth ? Wartość zgodna z poprzednimi testami
może być tylko dla drugiej wersji.

Mogę zaproponować jeszcze jeden pośredni test, który mi pomagał. Otóż,
w pierwszych próbach, można użyć tablicy transpozycji tylko do
sortowania ruchów. W zależności od tego jak (poza tą techniką)
sortujesz ruchy i czy używasz iteracyjnego pogłębiania, powinno
znacznie albo bardzo znacznie przyspieszyć.

Kolejna propozycja: użyj tablicy transpozycji bez alpha-beta. Sprawdź
czy ilość węzłów w poddrzewie jest identyczna. Jeśli nie będzie
identyczna, to masz na 100% błąd. Warto te wyniki porównać z
innym programem na co najmniej 1000 pozycji.
Tam kilka moich testów do porównania:
http://brodacz100.republika.pl/perft.htm




> W dyskusji dotyczącej artykułu jedna z osób narzeka, że i u niej
> algorytm z Wikipedii nie działa, inna osoba jednak kontruje, że algorytm
> jest na pewno poprawny, a wina jest po stronie niewłaściwego
> zaimplementowania tegoż algorytmu.
Wszystko zależy od pozostałych algorytmów. Inaczej będzie z pogłębieniami,
inaczej z qsearch, a już zupełna masakra z null-move...


> Spędziłem jeszcze trochę czasu na poszukiwaniach innych opisów
> alpha-beta prunning with memorization, ale nic lepszego niż to co w
> Wikipedii nie znalazłem.
>
> Próbuję więc samodzielnie przemyśleć problem i w pełni go zrozumieć...
> W algorytmie z Wiki w tablicy transpozycji dodatkowo zapisywana jest
> flaga, która przyjmuje stany: UPPERBOUND, LOWERBOUND, EXACT.
> Moim zdaniem to jednak za mało informacji by móc rozstrzygnąć czy można
> taki wpis w przyszłości wykorzystać.
> Moim zdaniem trzeba zapisać w tablicy transpozycji parametry alpha
> (alphaOrig wg algorytmu Wiki) i beta przy jakich został obliczony wynik
> gry dla danej transpozycji.
>
> Zapamiętuję więc dla każdej transpozycji parametry alpha i beta (bardzo
> niechętnie bo pożerają pamięć).
> Gdy natrafię ponownie na daną transpozycję dokonuję sprawdzenia czy
> alpha_current >= alpha_memorized oraz czy beta_current <= beta_memorized.
A depth >= curr_depth?
W wiki jest właśie większy równy:
if ttEntry is valid and ttEntry.depth >= dept



> Z obliczonej uprzednio wartości korzystam tylko wtedy, gdy oba powyższe
> warunki są spełnione. No i chyba działa... tj. wyniki zgodne oraz
> otrzymałem najszybszą wersję algorytmu.
>
> Pozostają jednak wątpliwości czy nie da się tu czasem czegoś ulepszyć:
> np. gdy nie da się użyć wartości z tablicy transpozycji to być może da
> się jakoś zmodyfikować parametr alpha lub beta by uzyskać lepszą
> wydajność. Algorytm z Wiki ma coś takiego:
>
> if ttEntry.Flag = EXACT
> return ttEntry.Value
> else if ttEntry.Flag = LOWERBOUND
> ? := max( ?, ttEntry.Value)
> else if ttEntry.Flag = UPPERBOUND
> ? := min( ?, ttEntry.Value)
> endif
> if ? >= ?
> return ttEntry.Value

Używam ciut innej implementacji i ciut innego algorytmu niż na wiki.
Moja działała minimalnie szybciej i przeszukiwała minimalnie mniej węzłów
(lepiej obcinała). Niestety nie mam pod ręką metakodu, jeśli znajdę,
to podrzucę.

Opieram się na metakodzie który udostępnił kiedyś w sieci ten autor:
https://chessprogramming.wikispaces.com/Bruce+Morela
nd
Niestety samego metakodu już nie mogę znaleźć.

Widać tylko kod samej alpha-bety:
https://cs.marlboro.edu/code/perl/TicTacToe/bruce-mo
reland/alphabeta.html




> Cały czas też się zastanawiam, czy faktycznie nie wystarczy wspomniana w
> Wiki flaga, zamiast pełnej informacji alpha, beta.
> Różne próby robione "na macanta" dają jednak niepoprawne wyniki...
Wystarczy.


> Jak powinien wyglądać algorytm alpha beta prunning z memoryzacją?
> Może jednak ten z Wiki jest dobry, a ja popełniam błąd w implementacji?
Ten na wiki (chyba) jest poprawny, aczkolwiek Bruce Moreland podał
znacznie bardziej zwartą i czytelną wersję, a poza tym, u mnie
obcinała ona więcej węzłów.


Pozdrawiam