własny projekt

[migawron]

mamy na forum tworcow trzech projektow BOINC - Enigma, Merssine, Radioactive
wiec na pewno ktos pomoze :)

A tak BTW to można by takie zdanko umieścić gdzieś na głównej stronie, że członkowie B@P tworzą, bądź współtworzą kilka projektów BOINC, jak by nie było to jest się czym pochwalić. Co Wy na to?

[Rysiu]

Jeszcze Goldbach się gdzies zapodział w twej liście :D

Aktualnie nieaktywny  :(

[Troll81]

ale wszak twórca jego serwer postawił i aplikację napisał...

[mariotti]

Jeszcze Goldbach się gdzies zapodział w twej liście :D

Pomału bo dostałem zadyszki :)
Co to jest ten Goldbach? :)
Pozdrawiam

[Rysiu]

Co to jest ten Goldbach? :)

Projekt BOINC, który jest nieosiągalny  :deadman:

[Troll81]

Goldbach Conjencture - testuje a raczej testował hipotezę Goldbacha.

[mariotti]

No dobra...

Pościągałem z svna co kazali na stronie.
Wszedłem do przykładów, znalazłem przykład o nazwie example_app.
Na dzień dobry błąd kompilacji, nie widzi pliku config.h. Wszedłem do
źródła, zakomentowałem #include "config.h" w wiersuz 43.
Po zakomentowaniu kopilacja się powiodła. Kompilator zrobił
plik o nazwie libstdc++.a. No i dalej leżę, nie wiem co z tym plikiem
zrobić :)

Pozdrawiam

[goofyx]

I tu kolejna kwestia, raczej lepiej zeby zadania byly odpowiednio dlugie (4-6h) to zminiejszyloby ruch moze

Niestety pierwszy projekt z AI będzie miał jeden task na około 1-2 minuty. Transfery są małe, ale częste.
Nie wiem czy BOINC robi jakiś narzut na transfer.

albo nawet zadania o czasie 200h :D jak pokazuje przykład primegrid :D da się

200h na jednym kompie jest niemożliwe. Uczenie to proces iteracyjny. Chodzi o
to aby iteracji było dużo, tysiące albo miliony. Dla metody magnetycznej idealnie
jest 100-1000 komputerów i na każdym 1 minuta obliczeń.

Myślę że większym problemem będzie obsłużenie ruchu na serwerze i obróbka wyników/bieżące generowanie próbek niż brak chętnych.

Nie wiem jaki narzut na obsługę jest ze strony oprogramowania BOINC. W metodzie magnetycznej
klient będzie musiał odebrać dwie listy parametrów. Lista będzie mała, rzędu 50-2000 liczb w pliku
tekstowym. Program zmieniany będzie rzadko, po zmianie też będzie musiał go odebrać. Potem klient
liczy 1-2 minuty i wysyła wynik jako jeden wiersz tekstowy. I znowu pobór dwóch list i
tak w kółko.  Obróbka danych jest łatwa. Trzeba wyłonić zwycięzce, zrobić krok iteracyjny,
wylosować trochę liczb i następna iteracja gotowa.

1-2 minuty na jedno WU?
Kolego to ja i moje ok. 50 (na początek) wątków lubimy ten projekt :D

[mariotti]

1-2 minuty na jedno WU?
Kolego to ja i moje ok. 50 (na początek) wątków lubimy ten projekt :D

Co to jest WU?

Jedna iteracja w metodzie magnetycznej trwa tak długo aż się zakończą wszystkie
gry, czyli aż się zakończy cały turniej. Jeśli użyjemy tyle komputerów ile jest
gier w turnieju to jedna iteracja trwa tyle ile trwa jedna gra. Jeśli gra będzie trwała
godzinę, to jedna iteracja trwa aż godzinę, jeśli minutę, to tylko minutę. Chodzi o to
aby maksymalizować ilość iteracji i nie zaniżać zbytnio czasu jednej gry. Do
tej pory ustawiałem od 40 do 60 sekund na jedną grę i działało.

Jeśli w turnieju startuje 10 wersji programu to mamy 10*9/2=45 par i 45*2=90
gier. Jeśli użyjemy 30 wersji to mamy 30*29=870 gier. Tak więc przy 10ciu
wersjach dodanie więcej niż 90 komputerów nie przyspiesza, a przy 30tu
dodanie więcej niż 870 komputerów nie przyspiesza. Jedyne co można zrobić
to skracać czas rozgrywki.

Owszem można użyć 30 wersji i zamiast 870 gier zrobić 8700. Da to
dokładniejszy wynik turnieju. Taki turniej trwa 10 razy dłużej ale uczenie
przebiega szybciej, czyli można uzyskać ten sam efekt w mniejszej
ilości iteracji. Nie wiem jak sprawa wygląda w szachach, nie mam mocy
obliczeniowej aby sprawdzić. Ale gdy testowałem metodę magnetyczną
na prostszych zadaniach to wynikało jednoznacznie że coś takiego się
nie opłaca. Np. czas turnieju wydłużał się 10 razy, a ilość iteracji malała
8 razy.

Niemniej w przypadku obliczeń rozproszonych sprawa będzie wyglądała
inaczej. Załóżmy że mamy 90 komputerów i turniej złożony z 90ciu gier.
Teoretycznie, jeśli ustawimy czas gry na 1 minutę, to możemy robić
jedną iterację co 1 minutę. Jednak gdy choć jeden komputer padnie, to
czekamy aby rozpoznać że padł i potem wysyłamy drugiemu aby policzył
to zadanie jeszcze raz. Czyli wszystko może się wydłużyć z tej jednej
minuty np. do 2-3 minut. Do tego iteracja ucząca też zajmuje trochę
czasu. Iterację uczącą wykonuje tylko serwer a komputery wolontariuszy
czekają bezczynnie. Tak więc wydaje się że lepiej będzie wysłać do
każdego komputera np. po 10 'losowych' gier. Można od razu wysłać
częściowo zdublowane gry, a jeśli któryś komputer padnie to po prostu
można zignorować ten fakt. Metoda magnetyczna jest odporna na
małe losowe zaburzenia, ale muszą być to naprawdę losowe(!) zaburzenia
niczym nie obciążone.

To takie luźne przemyślenia... dopracowanie szczegółów nie jest ani
proste ani oczywiste... będzie trzeba próbować, sprawdzać co jest
problemem i usuwać problemy aż do skutku.

Pocieszające jest to, że metodę testowałem u siebie na sześciu
rdzeniach. Uruchamiałem ją wielokrotnie dla zadań o różnej trudności.
Jeśli mnie pamięć nie myli, to 6 razy na 7 odnalazła wyraźnie lepsze
parametry niż wpisane przeze mnie na instynkt szachisty. Jeśli u mnie
działała to na obliczeniach rozproszonych też powinna działać, tyle
że szybciej. Wraz ze wzrostem ilości iteracji uczących można optymalizować
większą ilość parametrów. Do tej pory optymalizowałem od 7 do 30 parametrów.
Obecnie trwa optymalizacja ponad 50 parametrów. Po miesiącu optymalizacji
zrobiłem pomiar siły i widzę wyraźny wzrost. Tak więc to powinno działać.

Z kolei smutne jest to że metoda magnetyczna nie nadaje się do
wszystkich zadań. Np. metoda magnetyczna nie zbuduje architektury
sieci neuronowej. Może jedynie znaleźć wartości wag w pobliżu
optymalnych.

Pozdrawiam

[migawron]

WU - work unit, pojedyncza próbka danych przesyłana z serwera projektu do komputera z zainstalowanym klientem boinc.

[mariotti]

WU - work unit, pojedyncza próbka danych przesyłana z serwera projektu do komputera z zainstalowanym klientem boinc.

A no tak, powinienem już to wiedzieć.
Po wstępnych przemyśleniach, jakby było za dużo komputerów to optymalny WU na 2 minuty.
Jeśli za dużo nie będzie, to optymalna w granicach 5-20 minut, aby minimalizować ilość
transferów. A może po prostu jeden transfer na 5-20 WU, można tak?
Pozdrawiam

[krzyszp]

Generalnie Ty ustawiasz na serwerze dzienny limit próbek (WU) jakie może otrzymać komputer wolontariusza, a dodatkowo jest to zależne jeszcze od jego przydzielonych zasobów dla Twojego projektu oraz ustawionego przez niego czasu, na jaki ma pobrać zapas próbek. Im wolontariusz ma ten czas ustawiony dłuższy i limity większe, tym stara się pobrać więcej próbek. Ja na przykład mam teraz w systemie z którego piszę kilkadziesiąt próbek z POEM, ale tylko jedną Radioactive (bo R@H daje tylko jedną próbkę na raz).

[mariotti]

Generalnie Ty ustawiasz na serwerze dzienny limit próbek (WU) jakie może otrzymać komputer wolontariusza, a dodatkowo jest to zależne jeszcze od jego przydzielonych zasobów dla Twojego projektu oraz ustawionego przez niego czasu, na jaki ma pobrać zapas próbek. Im wolontariusz ma ten czas ustawiony dłuższy i limity większe, tym stara się pobrać więcej próbek. Ja na przykład mam teraz w systemie z którego piszę kilkadziesiąt próbek z POEM, ale tylko jedną Radioactive (bo R@H daje tylko jedną próbkę na raz).

Ok, fajnie że jest konfiguracja. A jak jest zdefiniowana próbka?
Chodzi mi o to, aby optymalizować transfer. Będzie na pewno kilka 'rodzajów' pobierania.
1) Największy na początku - program wraz  z bibliotekami.
2) Dość duży po zmianie w programie, np. po usunięciu błędu.
3) Mały na starcie iteracji - wystarczy nowa baza parametrów dla wszystkich wersji.
4) Maleńki przed samym zadaniem - wystarczą dwie małe liczby całkowite wskazujące która para ma zagrać partię.
Jeśli za każdym razem trzeba pobrać wszystko to czarno widzę gry na 1 minutę :)
Pozdrawiam

[krzyszp]

Nie, nie trzeba pobierać wszystkiego za każdym razem. Raz (do następnej zmiany wersji pliku) pobiera się aplikację liczącą, na bieżąco pobiera się właśnie tzw. próbki (czyli właśnie WU - Work Unit), oraz ewentualnie pliki konfiguracyjne, właśnie to wszystko definiujesz na serwerze. Natomiast generalnie odsyłać można min. jeden plik - wynik obliczeń, często też odsyła się raport błędów lub dane debuggera (jeśli występuje).
Użytkownik ma także możliwość (jeśli administrator serwera to przewidział) zmiany części konfiguracji (np. wybór długości próbek, pod-projektu, itd) - ale to już zależy od Ciebie jako administratora.

Generalnie najwięcej na ten temat z naszego grona wie chyba TJM - ma bardzo dużą wprawę i praktykę w stawianiu i administrowaniu serwerem, a także w budowaniu aplikakacji pod BOINC, spróbuj na naszym kanale IRC - on prawie zawsze tam jest :)

[mariotti]

Nie, nie trzeba pobierać wszystkiego za każdym razem. Raz (do następnej zmiany wersji pliku) pobiera się aplikację liczącą, na bieżąco pobiera się właśnie tzw. próbki (czyli właśnie WU - Work Unit), oraz ewentualnie pliki konfiguracyjne, właśnie to wszystko definiujesz na serwerze. Natomiast generalnie odsyłać można min. jeden plik - wynik obliczeń, często też odsyła się raport błędów lub dane debuggera (jeśli występuje).
Użytkownik ma także możliwość (jeśli administrator serwera to przewidział) zmiany części konfiguracji (np. wybór długości próbek, pod-projektu, itd) - ale to już zależy od Ciebie jako administratora.

Generalnie najwięcej na ten temat z naszego grona wie chyba TJM - ma bardzo dużą wprawę i praktykę w stawianiu i administrowaniu serwerem, a także w budowaniu aplikakacji pod BOINC, spróbuj na naszym kanale IRC - on prawie zawsze tam jest :)

Super, to skorzystam w najbliższej przyszłości :)
Teraz muszę rozgryźć co z tym skomplikowanym libem się robi :)
Pozdrawiam

[migawron]

Jak tam kolego idą prace, dłubiesz coś? Bo (bez nacisku oczywiście  :whip:  : XD) czekamy na jakieś newsy.

[mariotti]

Jak tam kolego idą prace, dłubiesz coś? Bo (bez nacisku oczywiście  :whip:  : XD) czekamy na jakieś newsy.

Dłubię, testuję i nieustannie myślę ;-) Od ostatniego czasu testowałem dwie
"nowe" metody samouczenia (oczywiście na szachach). Niestety nie mam jednoznacznych
rezultatów, raz uczenie działa, potem minimalnie zmienię warunki uczenia i już
nie działa. Nie wiem co od czego zależy... strasznie trudna sprawa.

Poza tym czytałem intensywne źródła najlepszych programów na świecie i
zastanawiam się dlaczego one są takie mocne a mój przy nich taki kiepski.
W kodzie nie widzę dużych różnic pomiędzy moim programem a tymi najlepszymi,
wszystko co najważniejsze wygląda bardzo podobnie, albo wręcz tak samo.
Czyżby drobne szczegóły decydowały o  ogromnej różnicy w sile gry? Może
czegoś ważnego nie zauważam, nie wiem. W turnieju mój z tymi programami
wygrywa jedną grę na 30, a czasami tylko jedną grę na 1000.

Chcę przygotować coś co będzie miało duże szanse na sukces. Byłoby
mi dziwnie jakby po tysiącu lat obliczeń nie było żadnych wyraźnych postępów, a
niestety w przypadku tak trudnego problemu jest to całkiem realne zagrożenie.
Jeśli metoda uczenia ma być kiepska, albo będzie wymagała gigantycznych
mocy obliczeniowych to lepiej niech wolontariusze liczą leki - więcej pożytku.

Nie wiem czy kogoś na tym forum zaciekawi sama metodyka jaką testuję.
To jest forum o obliczeniach rozproszonych, uczenie maszynowe w zastosowaniu
do szachów to "trochę" inny temat, ale spróbuję kilka zdań na zaczepkę.
Może ktoś konstruktywnie skrytykuje to i owo, zamiast zwyczajnie opieprzyć ;-)

Najgorszy problem z jakim się zmagam to dostosowanie do szczególnych cech
programów. Przykładowo mam 3 programy, nazwijmy je A, B i C. Programy
A i B mogą być dowolnymi programami. Mogą być jakimiś wersjami napisanymi
przeze mnie, albo przez innych autorów. Program C jest napisany przeze mnie i
będzie poddawany uczeniu. Program C uczy się grając z programem A, po
czym z programem B jest wykonywane coś w rodzaju walidacji krzyżowej.
Na początku program C gra z programem A wiele gier, potem tak samo z
programem B. Załóżmy że w dużym turnieju program C z programem A
zdobył 40% punktów, a z programem B 45%. Potem program C się uczy jakąś
metodą. Z samym uczeniem zwykle nie mam większych problemów, uczenie z
reguły przebiega szybko i skutecznie. Więc po uczeniu program C z programem A
może zdobywać znacznie więcej niż początkowe 40%, powiedzmy 75%. Następnie
robię turniej kontrolny z programem B, który nie brał udziału w uczeniu. No i
efekt jest taki, że z reguły z programem B gra gorzej niż na początku, np.
spada z początkowych 45% do 30%.

Kiedyś ciekawiło mnie czy można ten problem rozwiązać przez zastąpienie
programu A i B całymi zbiorami programów. Napisałem kiedyś prostą grę
opartą po prostu na tabeli wypłat. Potem zwiększałem ilość programów w
grupie uczącej i testowej (testowa to da do walidacji krzyżowej). Wyszło mi że w grupie
uczącej musi być minimum 5tys programów i trzeba zrobić dwie rundy
gier każdy z każdym, czyli razem około 50mln gier. Dopiero przy 50mln
gier uzyskiwałem potwierdzenie na zbiorze testowym.

Jakby jedna gra trwała minutę, to 50mln gier wymaga 95lat obliczeń :)
50mln to oczywiście jedna iteracja, potem trzeba robić kolejne.
Pomimo wykonania tak dużej ilości gier w jednej iteracji uczącej, nadal
nie wiadomo co zrobić z wynikami, aby uzyskać największą efektywność.
Nie wiadomo czy mutować tylko zwycięzce, czy może kilka najlepszych
programów, czy może zrobić krzyżowanie (tak jak w algorytmie
genetycznym) pewnej ilości najlepszych programów. Błąd na tym etapie
może znacznie zwiększyć ilość iteracji uczących. Poza tym 50mln gier
to wynik jaki uzyskałem dla znacznie prostszej gry niż szachy, w
szachach być może potrzeba więcej. Słyszałem z
niepotwierdzonego źródła że w szachach trzeba wykonać setki milionów
gier.

Opracowanie lepszego algorytmu uczącego wydaje się konieczne, nawet
gdy ma się do dyspozycji sieć BOINC.

Na razie widziałem w praktyce dwa algorytmy które cechowały się dość
dużą skutecznością, co niestety było okupione ich ograniczeniami.

Pierwszy z tych algorytmów to metoda bazująca na aproksymacji funkcji.
Dobrze sprawowały mi się proste funkcje, np. liniowa albo sigmoidalna,
czyli tak jakby sztuczna sieć neuronowa z jednym liniowym albo sigmoidalnym
neuronem. Bardziej skomplikowane funkcje nie działały mi, niestety
też nie jestem pewien dlaczego. Ogólnie metoda polega na tym, że
ręcznie opracowujemy zestaw cech. Np. piszemy procedury które liczą
ilość poszczególnych bierek, liczą ilość pionków osłaniających króla itd.
Potem rozgrywamy pewną ilość gier, raczej małą, 20 wystarczy w zupełności.
Z gier budujemy wektory uczące. Wektory opisują powyższe cechy jakie
pojawiały się w rozgrywkach, a na wyjściu mają {+1,0,-1} w zależności
od tego czy wygrały białe, czy był remis, czy czarne. Ostatecznie na
tak spreparowanych danych robimy metodę najmniejszych kwadratów i
proces zapętlamy. W jednej rozgrywce jest dość dużo ruchów,
każdy ruch daje wektor uczący, więc ilość danych uczących szybko narasta.
Już po wykonaniu 20 iteracji po 20 gier w każdej, algorytm uzyskuje
zbieżność do jakiegoś punktu. Niestety punkt ten nie jest to ani
globalny optimum, ani nawet lokalnym w sensie dobrej gry w szachy.
Po prostu jest to jakiś punkt przyciągania do którego zmierza ten algorytm.
Zdaje się że nigdy nie zaobserwowałem żeby ta metoda kompletnie się nie
sprawdziła, nigdy nie zdarzyło mi się aby parametry były kompletnie
beznadziejne, zawsze z zupełnie losowych parametrów metoda osiągała w
miarę sensowny poziom gry - to pewna zaleta.

Zastanawiam się jakie są możliwości adaptacji powyższej metody do
obliczeń rozproszonych. Co można zrobić, jeśli ta metoda już po
kilku godzinach obliczeń na jednym komputerze osiąga swój punkt
przyciągania? Oczywiście dobrze byłoby też odpowiedzieć na pytanie
dlaczego bardziej skomplikowane funkcje nie działały. W tej chwili
mam kilka przemyśleń.

Można wygenerować setki milionów początkowych układów i z każdego
rozegrać kilka partii. Wydaje się, że duża różnorodność układów
początkowych zapewni dużą różnorodność rozgrywek. W dodatku gdy
rozgrywki będą przeprowadzone różnymi wersjami programu i na różny
czas, to jeszcze bardziej zróżnicuje dane uczące. Dzięki sieci
BOINC można taką ogromną ilość gier przeprowadzić. Metoda doboru
parametrów liniowych jest jednoprzebiegowa, danych nawet nie
trzeba trzymać w pamięci ram. Można danymi zapchać cały twardy
dysk, a potem czas obliczeń trwa mniej/więcej tyle, ile czas
odczytu z dysku. Tak więc pod względem możliwości obliczeniowych metoda
bazująca na aproksymacji parametrów liniowych wydaje się realna.

Niestety nie jestem pozbawiony obaw jeśli chodzi o skuteczność.
Jeśli dane uczące nie są w żaden sposób obciążone, a model
jest dość dobry, to metody bazujące na najmniejszych kwadratach szybko
dochodzą do rozwiązań. Zwykle nie wymagają aż takiej ogromnej ilości
danych. Natomiast jeśli dane są obciążone to zwiększanie ilości danych w
niczym nie pomoże. Można jakoś odpowiedzieć na pytanie czy tak spreparowane
dane będą obciążone?
1) danych będzie dużo, to jest jakiś argument za tym że nie będą obciążone
2) dane będą z gier które zaczynają się z losowych otwarć - to też
   sugeruje że dane nie będą obciążone
3) program będzie grał sam ze sobą - to z kolei mocno sugeruje że
   dane będą obciążone.
Dwa argumenty za, jeden przeciw - nie wiem co myśleć. Do tej pory
różnorodność zapewniałem przez dodawanie losowych wartości
do parametrów przed rozgrywką. Np. gdy algorytm wyliczył wartość
skoczka równą 300, to program dodawał +/- 30 i grał kolejną grę.

Ponadto te losowe układy początkowe z których będą się rozpoczynały
rozgrywki nie mogą być w pełni losowe. Duża większość układów w
żadnej rozsądnej rozgrywce nie pojawi się. Konieczny byłby jakiś
dobry sposób opracowania zestawów początkowych.
Rozwiązanie tego problemu jakie obecnie przychodzi mi do głowy jest
mniej/więcej takie:
1) bierzemy szachownicę z układem początkowym
2) wykonujemy od 8 do 30 losowych ruchów, dochodzimy do jakiegoś układu
3) bierzemy dwa programy, jeden bardzo silny, a drugi słaby (ale nie beznadziejny)
4) rozgrywamy dwie gry, raz zaczyna program słaby, drugi raz silny
5) jeśli słaby nie wygrał ani razu, to układ klasyfikujemy jako rozsądny.

Metoda zawsze będzie miała dwie istotne wady. Po pierwsze nie nadaje się
do doboru(uczenia) parametrów przeszukiwania drzewa gry. Można
nią tylko dobierać parametry funkcji oceniającej. Po drugie metoda sama
nigdy nie dobierze sobie optymalnego zestawu cech. Cechy musi wybrać
programista. Jeśli programista nie wybierze wszystkich istotnych cech, to
nawet nieobciążone dane uczące nic nie pomogą.

To tak w skrócie moje rozterki dotyczące tej metody. Pomimo kilu zalet
są też wady. Nie mam pewności czy warto z taką metodą eksperymentować
na skalę globalną.



Druga z metod o których pisałem że przyzwoicie mi się sprawowały to
pewna odmiana algorytmu rojowego (metoda magnetyczna). Metoda
magnetyczna dawała mi zwykle dużo dokładniejsze rozwiązania niż metody
bazujące na aproksymacji funkcji. Też nie przypominam sobie aby metoda
magnetyczna wyprodukowała zupełnie bezsensowne wyniki - to chyba jest
ważne że na wiele prób w wielu różnych warunkach metoda dawała poprawę.
Z reguły ten sam program wyuczony metodą magnetyczną wygrywał około 60%-40%
z programem wyuczonym metodą bazującą na aproksymacji funkcji.

Czym się różni metoda magnetyczna od metody bazującej na aproksymacji?
1) Metoda nadaje się także do uczenia parametrów przeszukiwania drzewa
   gry - zaleta na korzyść metody magnetycznej.
2) Trwa dłużej - wada. Uczenie metodą wykorzystującą aproksymację trwało
   u mnie np. od 1-12 godzin, a metodą magnetyczną całe tygodnie. Im
   więcej parametrów tym większa różnica w czasie pomiędzy metodami.
3) Z symulacji na prostych zadaniach wynika, że metoda magnetyczna
   ma duże problemy z dotarciem do optimum. Zastępowałem rozgrywkę
   szachową jakąś wypukłą funkcją i sprawdzałem w jakiej odległości
   od optimum się zatrzymuje. Wyniki pokazują, że metoda stosunkowo
   łatwo znajduje rozsądne wartość, ale nawet w prostych zadaniach
   nie dociera do optimum. Myślę że metody bazujące na aproksymacji
   mają podobny problem, ale pewności nie mam.
4) Metoda słabo się zrównolegla. Z symulacji na prostych zadaniach
   wynika, że liniowe przyspieszenie uzyskuje się do około 50 komputerów.
   Metodę bazującą na aproksymacji można zrównoleglać prawie bez ograniczeń.
5) Ta sama wada co w przypadku metod bazujących na aproksymacji - metoda
   sama nie dobierze sobie zestawu parametrów. Jeśli programista źle
   ustali taki zestaw to efekty będą gorsze niż gdyby ustalił dobrze.
   Metoda sama nie odkrywa zależności, jedynie dobiera wartości parametrów i
   to nie optymalne, a jedynie rozsądne.

Tak więc rozterek kupa, a pewności nic :) Nie wiem czy jest sens zaprzęgania
sieci BOINC po to, aby po tysiącach lat obliczeń komputerowych uzyskać
przeciętny program - wydaje się to trochę dziwne.

Bym musiał mieć lepszą metodę uczenia... taką żeby po pierwsze działała
szybko, a po drugie dawała tym większy wzrost siły gry im dłuższe uczenie.

Albo bym musiał zrozumieć co jest źródłem siły tych najlepszych programów
na świecie. Wtedy bym mógł zrobić analogiczny program (oczywiście bez kopiowania
oryginału i łamania praw autorskich), a następnie jego fragmenty poddać uczeniu w
BOINC.

Tak czy inaczej nie umarłem, ani nie wycofałem się. Walczę z problemem, ale
nie ukrywam że walka idzie w krwi i pocie :)

Pozdrawiam

[PoznanskaPyra]

Chyba najdłuższy post w historii tego forum  :D Co do projektu niezła zagwostka.

[krzyszp]

Zastosuj metodę siłową - po prostu uwzględnij wszystkie trzy opcje, tworząc trzy aplikacji uczące. Po jakimś czasie wystaw je przeciwko sobie, to da Ci już jakiś pogląd na możliwości algorytmów.

BTW pamiętaj, że Twoje problemy z bardziej skomplikowanymi algorytmami mogą wynikać nie z ich słabości, ale z błędów implementacji.
W ramach ciekawostki (o ile już tego nie wiesz) zapoznaj się z typem FLOAT w bazach danych - drobiazg, przez który autorzy programów księgowych dorabiali się siwych włosów...

[mariotti]

Zastosuj metodę siłową - po prostu uwzględnij wszystkie trzy opcje, tworząc trzy aplikacji uczące. Po jakimś czasie wystaw je przeciwko sobie, to da Ci już jakiś pogląd na możliwości algorytmów.

Właśnie tak robię. Tyle tylko że tych metod jest więcej niż trzy i każdą można
sparametryzować na pierdylion sposobów. Właśnie z testów mniej/więcej wiem
jaka jest skuteczność niektórych z nich, ile trwa uczenie i jakich ograniczeń
można się spodziewać.

BTW pamiętaj, że Twoje problemy z bardziej skomplikowanymi algorytmami mogą wynikać nie z ich słabości, ale z błędów implementacji.
W ramach ciekawostki (o ile już tego nie wiesz) zapoznaj się z typem FLOAT w bazach danych - drobiazg, przez który autorzy programów księgowych dorabiali się siwych włosów...

Nie sądzę aby chodziło o błąd. Bym musiał napisać 10 razy tyle co poprzednio aby opisać
sposoby w jakie sprawdzałem poprawność :) W kodzie mam czasami drobne błędy, a
po ich usunięciu program gra... gorzej. Gdy czytam komentarze w źródłach innych
autorów, to widzę że mają podobne problemy. Piszą że wszelka logika wskazuje że
tutaj jest błąd, ale po poprawieniu program gra gorzej :)

W sieci można znaleźć źródła dwóch podstawowych programów szachowych. Jeden
nazywa się TSCP, a drugi Gerbil. Znam te źródła niemal na pamięć. Mój program gdy
miał zaimplementowaną podobną (lub nawet nieco mniejszą) funkcjonalność, to grał
trochę lepiej. Oznacza to że w innych programach z jakiś dziwnych powodów też
nie działa dobrze to co powinno działać i działa w tych programach najlepszych.
Coraz częściej myślę że chodzi o współpracę poszczególnych heurystyk. Po prostu w
słabszych programach poszczególne części nie współpracują z sobą tak dobrze
jak w silnych.

Natomiast metody uczenia są prościutkie, tam nie ma gdzie popełnić błędów. Poza tym
te metody bardziej skomplikowane gdzie trzeba aproksymować hesjan, albo odwrócić
macierz raczej mi działały. Mój problem nie polega na tym że nie działają, tylko na tym
że nie działają extra-rewelacyjnie ;-)

Co do typu FLOAT w bazach danych to nie wiem o co chodzi. Moje programy bazodanowe
które używają typu zmiennoprzecinkowego nie mają obserwowalnych problemów.

Pozdrawiam

[krzyszp]

Co do typu FLOAT w bazach danych to nie wiem o co chodzi. Moje programy bazodanowe
które używają typu zmiennoprzecinkowego nie mają obserwowalnych problemów.

W baaardzo wielkim skrócie i uproszczeniu, przy zapisie liczb w tym typie 4+4=3.999999999 ;)

[mariotti]

Co do typu FLOAT w bazach danych to nie wiem o co chodzi. Moje programy bazodanowe
które używają typu zmiennoprzecinkowego nie mają obserwowalnych problemów.

W baaardzo wielkim skrócie i uproszczeniu, przy zapisie liczb w tym typie 4+4=3.999999999 ;)

To ewidentnie błąd bazy danych. Nie spotkałem się nigdy z nim. Natomiast z powodu błędów
w kompilatorach owszem widziałem już kilka razy że 2+2=2. Chyba mam jeszcze gdzieś
screeny z debugera.
Pozdrawiam

[krzyszp]

To ewidentnie błąd bazy danych. Nie spotkałem się nigdy z nim.

To nie jest błąd:

Powoduje to, że reprezentacja liczby rzeczywistej jest tylko przybliżona, a jedna liczba zmiennoprzecinkowa może reprezentować różne liczby rzeczywiste z pewnego zakresu.

Kod [Zaznacz] Rozwiń

http://pl.wikipedia.org/wiki/Liczba_zmiennoprzecinkowa
Dokładniej ten problem przedstawiony jest w angielskojęzycznej wikipedii:

Kod [Zaznacz] Rozwiń

http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems

Dlatego w systemach księgowych najczęściej do zapisywania kwot pieniężnych używa się po prostu liczb całkowitych mnożąc kwotę razy 100 (żeby wyeliminować wartość po przecinku) - oczywiście tylko w przypadku przechowywania wartości już wyliczonej wcześniej.

[mariotti]

To ewidentnie błąd bazy danych. Nie spotkałem się nigdy z nim.

To nie jest błąd:

Powoduje to, że reprezentacja liczby rzeczywistej jest tylko przybliżona, a jedna liczba zmiennoprzecinkowa może reprezentować różne liczby rzeczywiste z pewnego zakresu.

Kod [Zaznacz] Rozwiń

http://pl.wikipedia.org/wiki/Liczba_zmiennoprzecinkowa
Dokładniej ten problem przedstawiony jest w angielskojęzycznej wikipedii:

Kod [Zaznacz] Rozwiń

http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems
Dlatego w systemach księgowych najczęściej do zapisywania kwot pieniężnych używa się po prostu liczb całkowitych mnożąc kwotę razy 100 (żeby wyeliminować wartość po przecinku) - oczywiście tylko w przypadku przechowywania wartości już wyliczonej wcześniej.

Na 100% jest to błąd bazy danych, za duża różnica jak na błąd powstały w
wyniku reprezentacji przybliżonej. Typy zmiennoprzecinkowe w każdym środowisku
(nie tylko w bazach danych) są związane z obliczeniami przybliżonymi. Przybliżenia
mają różny charakter. Jeśli to jest ważne, to trzeba się jakoś asekurować.
Mam jeden program w którym akurat mogę zignorować dokładność na którymś
miejscu po przecinku i dokonuję porównań na typie double w c++ instrukcją
if( a < b ). Na każdym procesorze ten program daje zupełnie inne wyniki i
w tym przypadku to jest normalne. Ale 4+4 nie może być równe prawie
cztery. Na 100% błąd bazy danych.
Pozdrawiam

[krzyszp]

Ja nie napisałem, że 4+4 daje prawie 4, tylko że 2+2 = 3.999999999...
I uwierz mi - to nie jest błąd i to "zjawisko" występuje w każdym silniku bazodanowym w pewnych warunkach.

[goofyx]

Zgadzam się, że to najdłuższy post na forum ;)
Nie wiem czy rozumiem to co chciałeś nam przekazać czyli to, że istnieje wiele algorytmów uczących się gry w szachy, każdy może mieć różne parametry i wykorzystywać różne metody uczenia <- tak?
A nie możesz przykładowo uruchomić projektu boinc w którym będzie wiele aplikacji uczących się przez jakiś okres lub przez pewną liczbę gier. Wtedy możesz porównywać wyniki poszczególnych algorytmów po np.: 1000 gier co przy np.: 1000 hostów/wątków rozegra się w ciągu doby i wybrać do dalszej nauki te które dają jakieś najlepsze wyniki.

[mariotti]

Ja nie napisałem, że 4+4 daje prawie 4, tylko że 2+2 = 3.999999999...
I uwierz mi - to nie jest błąd i to "zjawisko" występuje w każdym silniku bazodanowym w pewnych warunkach.

2+2=3.9(9) to co innego niż 4+4=3.9(9)
W każdym środowisku specyfika błędów zaokrągleń ma inny charakter.
Myślę że baza danych powierza obliczenia procesorowi, czyli problemy
bazy danych są analogiczne jak problemy procesora - ale pewności nie mam.

Są tak jakby dwa rodzaje problemów obliczeń przybliżonych. Pierwszy polega
na tym, że jedna liczba ma skończone rozwinięcie w systemie w którym
wklepujemy kod, a w systemie na którym operuje procesor już nie. Np.
2.0 + 2.0 powinno dawać dokładnie 4, gdyż zarówno w systemach dziesiątkowych
jak i w dwójkowych da się tą liczbę przechowywać dokładnie.

Zobacz taki programik:

#include <cstdio>
#include <cstdlib>

int main(int argc, char *argv[]) {
   double x,y,z;
   printf("podaj x:");
   scanf("%lf",&x);
   printf("podaj y:");
   scanf("%lf",&y);
   z = x + y;
   printf("x + y = %25.20lf\n",z);
   return 0;
}

I efekty jego działania:
podaj x:0.5
podaj y:0.5
x + y =    1.00000000000000000000

podaj x:0.3
podaj y:0.3
x + y =    0.59999999999999997780

Dla 0.5, choć to są też liczby ułamkowe, działa dokładnie. Dla 0.3 już nie. Problem wynika
właśnie dlatego, że 0.3 w systemie dwójkowym nie ma skończonego rozwinięcia. Problem
zachodzi także w drugą stronę, czasami w systemie dwójkowym jest skończone rozwinięcie, a
w dziesiątkowym już nie ma - tak więc w procesorze może być dokładny wynik, a podczas
wyświetlania już widzimy niedokładny - no chyba że wyświetlimy sobie dwójkowo :)

Drugi rodzaj problemu to utrata dokładność przy długotrwałych obliczeniach.
Małe błędy przy niektórych obliczeniach szybko się nawarstwiają, dodatni
współczynnik lapunowa itd.

Pozdrawiam

[krzyszp]

Generalnie, potwierdziłeś to, o czym pisałem - to nie jest błąd, to jest specyfika implementacji. Dodatkowo, dokładność rośnie wraz z możliwościami i architekturą komputerów (32-64-128 bitów). Niemniej, zboczyliśmy z tematu, ale... to może się przydać.
Z tego, co kojarzę, pewien współczynnik losowości (a takim w tym wypadku jest zaokrąglenie danych FLOAT), może mieć duży wpływ na twoje algorytmy... Oczywiście nie przy pierwszym powtórzeniu, nie przy dziesiątym, ale przy 10000 już tak - brałeś już to pod uwagę?

[mariotti]

Zgadzam się, że to najdłuższy post na forum ;)
Nie wiem czy rozumiem to co chciałeś nam przekazać czyli to, że istnieje wiele algorytmów uczących się gry w szachy, każdy może mieć różne parametry i wykorzystywać różne metody uczenia <- tak?

Tak, to chciałem powiedzieć. Przetestowałem wiele algorytmów nie tylko na szachach i
różnice w skuteczności są ogromne. Wszelkie znaki na niebie i ziemi pokazują że do
algorytmu genetycznego będzie potrzeba milionów komputerów i to mnie martwi. Tylko
algorytm genetyczny (albo coś podobnego do A.G.) może budować "fragmenty programu",
albo coś o równoważnych możliwościach jak fragmenty programu. Budowanie
fragmentów programu wydaje się być jedynym sposobem na to aby uzyskać nieograniczony
wzrost siły gry. Pozostałe metody są dużo szybsze, ale mają ograniczenia. Stosując
metodę magnetyczną program uzyska co najwyżej taką siłę gry jaka będzie wynikała z
jego architektury i potem uczenie nic nie daje, choćby się uczył milion lat.

A nie możesz przykładowo uruchomić projektu boinc w którym będzie wiele aplikacji uczących się przez jakiś okres lub przez pewną liczbę gier. Wtedy możesz porównywać wyniki poszczególnych algorytmów po np.: 1000 gier co przy np.: 1000 hostów/wątków rozegra się w ciągu doby i wybrać do dalszej nauki te które dają jakieś najlepsze wyniki.

Jestem prawie pewny jakie wymagania mają poszczególne metody i jakie mogą
dać wyniki. Nie ma czego sprawdzać. Jeśli mam zawracać gitarę wolontariuszom
to potem z tego powinny być dobre wyniki.

Co do rezultatów mam pewne obawy. Na chwilę obecną mogę przygotować dla
BOINC jedną z trzech metod:
1) metodę magnetyczną
2) metodę opartą na aproksymacji funkcji
3) metodę 'turniejową' - czyli ręcznie przygotowane programy do sprawdzenia jak grają.
Algorytm genetyczny nie przejdzie, by musiała cała polska liczyć 24h na dobę :)

Myślę żeby jeszcze popracować nad dwoma sprawami:
1) skuteczniejszy algorytm niż genetyczny ale o podobnych możliwościach
2) lepszy program bazowy, jakiś wzorowany na najlepszych programach na świecie.

Boję się że będzie wstyd jeśli po 5 latach uczenia program zagra gorzej niż przed
uczeniem, a z moich testów wynika że to jest realne zagrożenie.

Pozdrawiam

[krzyszp]

Zapominasz, że my pomagamy, bo chcemy - a czasem brak rezultatów jest tak samo ważny, jak te rezultaty...
W końcu, wyeliminowanie jakiś metod, to skrócenie drogi do lepszych rezultatów :)

[mariotti]

Generalnie, potwierdziłeś to, o czym pisałem - to nie jest błąd, to jest specyfika implementacji. Dodatkowo, dokładność rośnie wraz z możliwościami i architekturą komputerów (32-64-128 bitów). Niemniej, zboczyliśmy z tematu, ale... to może się przydać.
Z tego, co kojarzę, pewien współczynnik losowości (a takim w tym wypadku jest zaokrąglenie danych FLOAT), może mieć duży wpływ na twoje algorytmy... Oczywiście nie przy pierwszym powtórzeniu, nie przy dziesiątym, ale przy 10000 już tak - brałeś już to pod uwagę?

Tego typu błędy, nawet jeśli je mam, w moim przypadku nie mają znaczenia.
I tak i tak używam liczb losowych. Niedokładności obliczeń na typie FLOAT
u mnie są traktowane jako dodatkowe źródło losowości. Uczenie szachów
to inne zagadnienie niż np. symulowanie ruchu planet układu słonecznego.
W przypadku ruchu planet gdy obliczymy trochę niedokładnie położenie np.
Jowisza, to w następnej iteracji jako punkt wyjścia używam złej pozycji
początkowej. W następnej znowu mamy niedokładność obliczeń + błąd
z poprzedniej iteracji. Gdy używamy prostego schematu np. Eulera to
dokładność typu DOUBLE wyczerpuje się bardzo szybko, nie wiem czy
schematem Eulera da się układ słoneczny symulować chociaż na
tydzień w przód.

Tak czy inaczej powyższe problemy nie dotyczą uczenia szachów. Nie
dotyczą żadnej z metod które stosowałem.

Gdy używamy metody bazującej na aproksymacji funkcji nieliniowej, a
jako metodę uczenia weźmiemy jakąś odmianę algorytmu zmiennej
metryki, to owszem taki problem występuje. W hesjanie nawarstwiają
się błędy w analogiczny sposób jak w przypadku symulowania układu
słonecznego. Problem te jednak rozwiązuje się bardzo prosto - metodę
resetuje się co pewną ilość iteracji. I tak i tak trzeba ją zresetować z
innych powodów.

Problemy związane z uczeniem programu szachowego są takie same
jak problemy z symulacjami MC. Ilość symulacji rośnie wykładniczo
względem uzyskiwanej dokładności.

Zobacz taki programik:
int main(int argc, char *argv[]) {
   double moneta[] = {0,0};
   srand(234);
   for( int i=0 ; i<10000 ; i++ )
      moneta[rand()%2]++;
   printf("szansa na reszkę = %lf\n",moneta[0]/(moneta[0]+moneta[1]));
   return 0;
}

Program ma robić symulację rzutu uczciwą monetą. Wykonuje
10tys rzutów i sprawdza czy wyszło pół na pół. Na kompilatorze
którego w tej chwili używam wychodzi że szansa na reszkę
wynosi 50.1%.

Z programem szachowym jest tak samo jak z monetą (plus kilka
dodatkowych problemów). Choć są dwa programy które grają
z taką samą siłą i choć rozegrano 10tys gier to wychodzi że
jeden z nich wygrał, bo np. zdobył 50.1% punktów. Choć w
celu testu przeprowadzono aż 10tys gier to wynik nie jest
dokładny. W trakcie uczenia od czasu do czasu się zdarza że
program słabszy wygrywa z silniejszym dlatego że ten
słabszy miał więcej szczęścia. Jedyne co można zrobić aby
temu problemowi zapobiegać to rozgrywać setki milionów gier.

Powyższy program dla 100mln symulacji daje wynik:
50.003764%, więc znacznie dokładniejszy niż 50.1%.
Dla miliarda symulacji mam 50.001306%. Czas symulacji
wydłużył się z 10tys do 1mld (100tys razy) a dokładność
przesunęła się tylko o dwa miejsca po przecinku.

Powyżej pisałem że jedyne co można zrobić to zwiększać
ilość symulacji albo gier. Nie jest to w 100% prawdą. Jak
się okazuje można jeszcze zastosować metodę uczenia
odporną na chwilowe błędy. Wszystko wskazuje na to że
metoda magnetyczna ma taki potencjał. W metodzie
magnetycznej wystarczy że lepszy program wygrywa z
pewnym prawdopodobieństwem i już obserwuje się postęp.
Za to metoda magnetyczna sprawia inne problemy...

Ponad to z szachami są dodatkowe problemy względem
symulacji monety. Chodzi o to że relacja "jest lepszy"
często nie jest przechodnia. Czyli program A wygrywa
z programem B, program B wygrywa z programem C, a
program C (o dziwo) wygrywa z programem A. Czyli jeśli w
uczeniu program będzie grał sam ze sobą, to jest duże
ryzyko że dostosuje się do gry z samym sobą. Wielokrotnie
obserwowałem jak mój program uczył się grać z niby
reprezentatywnym zestawem przeciwników, bo brałem
do turniejów aż 30 programów różnych autorów. Potem te
30 wymieniałem na 30 jeszcze innych i grał gorzej niż
przed uczeniem. Raczej nie chodzi o błąd, po prostu nauczył
się grać dobrze tylko z określonymi przeciwnikami.

Mój eksperyment z wczoraj:
Wziąłem jedną wersję programu. Wywaliłem z niej pewną cechę i
przepisałem od nowa. Zrobiłem turniej i takie wyniki:
bearded46_old    240  62.29%
      bearded64    240  37.71%
240 gier, stara wersja zdobyła 62% punktów, nowa 37. Jak widać
nowa wersja jest gorsza. Ale wniosków nie można wyciągać
pochopnie, więc parametry nowej cechy poddaję uczeniu.

Uczenie polega na tym, że 100 razy dodaję małe losowe wartości
do parametrów i robię turniej. Wygrany program przechodzi dalej i
znowu do wygranego małe losowe wartości, znowu turniej itd. W sumie
wykonałem 100 iteracji. Po stu iteracjach znowu kontrolny turniej ze
starą wersją:
bearded46_old    240  66.88%
      bearded64    240  33.12%
No i mamy niespodziankę, po uczeniu program spadł z 37% do 33%.

Znowu myślę że nie ma co pochopnie wyciągać wniosków i daję
jeszcze 100 iteracji uczących:
bearded46_old    240  66.25%
      bearded64    240  33.75%
Widać że minimalnie się polepszył, wiec jeszcze 100 iteracji uczących:
bearded46_old    240  67.08%
      bearded64    240  32.92%
Tym razem spadł.. no ale to nic, jeszcze raz 100 iteracji uczących i jeszcze,
w sumie w turnieju kontrolnym wyglądało to tak:

37.71%
33.12%
33.75%
32.92%
33.33%
32.50%
32.71%
31.25%
30.21%
28.96%
31.25%
30.83%

Nie widać postępu. Program nigdy nie przekroczył początkowego 37.71%. Prawdopodobnie
jest jak mówiłem. Po pierwsze jest za mało gier aby wyłonić silniejszy program, a po drugie
wyłania się ten który dostosował się do specyficznych warunków.

Po tym zrobiłem dwie dwie tury po 100 iteracji metodą magnetyczną. Wyniki takie:
32.71%
31.46%
Czyli po pierwszej turze się odbił od poprzednich 30.83% i wskoczył na niecałe 33% - ładnie.
Ale po drugiej znowu spadł do 31.46%. Trzecia tura (z innymi parametrami) właśnie trwa...


Pozdrawiam

[mariotti]

Zapominasz, że my pomagamy, bo chcemy - a czasem brak rezultatów jest tak samo ważny, jak te rezultaty...
W końcu, wyeliminowanie jakiś metod, to skrócenie drogi do lepszych rezultatów :)

Ja to wiem ;-) Ale gdy np zawarłem w swojej pracy mgr rozdział "algorytm genetyczny
nie jest efektywny" to musiałem go wrzucić że niby piszę bzdury ;-)
A tak poważnie to jednak chcę uruchomić coś co będzie miało jednocześnie duży
potencjał i szansę na zrobienie postępu jeszcze w tym wieku :)
Pozdrawiam

[kotfryc]

Nie widać postępu. Program nigdy nie przekroczył początkowego 37.71%. Prawdopodobnie
jest jak mówiłem. Po pierwsze jest za mało gier aby wyłonić silniejszy program, a po drugie
wyłania się ten który dostosował się do specyficznych warunków.

Może program/metoda jest dobry, ale dałeś mu złe warunki do rozwoju?

W toku ewolucji gatunek musi również konkurować ze swoimi krewniakami, może każda nowa wersja powinna również grać turniej ze starymi wersjami? Daje to o wiele dłuższą metodę selekcji, ale być może bardziej skuteczną.

[mariotti]

Nie widać postępu. Program nigdy nie przekroczył początkowego 37.71%. Prawdopodobnie
jest jak mówiłem. Po pierwsze jest za mało gier aby wyłonić silniejszy program, a po drugie
wyłania się ten który dostosował się do specyficznych warunków.

Może program/metoda jest dobry, ale dałeś mu złe warunki do rozwoju?

W toku ewolucji gatunek musi również konkurować ze swoimi krewniakami, może każda nowa wersja powinna również grać turniej ze starymi wersjami? Daje to o wiele dłuższą metodę selekcji, ale być może bardziej skuteczną.

Zgadzam się całkowicie, właściwie to o tym samym pisałem. Problem w tym, że na dużo
prostej grze niż szachy wyszło mi że owych konkurentów (obojętnie jaka jest ich analogia
do tych z ewolucji naturalnej) musi być minimum 5tys. Nie da rady tego policzyć
nawet cała sieć BOINC :)
Pozdrawiam

[goofyx]

A nie możesz przykładowo uruchomić projektu boinc w którym będzie wiele aplikacji uczących się przez jakiś okres lub przez pewną liczbę gier. Wtedy możesz porównywać wyniki poszczególnych algorytmów po np.: 1000 gier co przy np.: 1000 hostów/wątków rozegra się w ciągu doby i wybrać do dalszej nauki te które dają jakieś najlepsze wyniki.

Jestem prawie pewny jakie wymagania mają poszczególne metody i jakie mogą
dać wyniki. Nie ma czego sprawdzać. Jeśli mam zawracać gitarę wolontariuszom
to potem z tego powinny być dobre wyniki.

1. skoro to wiesz to po co chcesz projekt boinc? <- bez urazy
2. pozwól aby to wolontariusze zdecydowali czy podoba im się twój projekt czy nie
3. ja osobiście z chęcią liczyłbym projekt taki jak twój, ale a możliwością porównania poszczególnych algorytmów <- ale to twoja decyzja
4. co znaczy: "dobre wyniki"? jeśli chodzi ci o algorytm który będzie grał najlepiej to ok <- ale to też możesz wrzucić do gry kilka algorytmów i na podstawie porównania określić, że dany algorytm jest najlepszy. Ludziom się to spodoba, że widzą różnice między algorytmem A i B <- może nawet ktoś się tym zainteresuje i znajdzie jakieś nowe rozwiązanie tego problemu. W przeciwnym wypadku twój projekt będzie kolejnym, w którym będzie się walczyć o dobrą pozycję :(

[mariotti]

1. skoro to wiesz to po co chcesz projekt boinc? <- bez urazy

Wiem w odniesieniu do kilku metod które testowałem. Nie oznacza to że
znam wszystkie i że nie istnieje lepsza metoda (nie oznacza to też że się
nie mylę w jakimś momencie).

Zobacz poniższy fragment kodu:
https://github.com/mcostalba/Stockfish/blob/master/src/search.cpp
Wiersze od 1324 do 1362. Tamta procedura sprawdza czy szach jest
niebezpieczny, czy może da się łatwo i bez strat uciec królem. Zastanawiam
się jakiej użyć metody uczenia aby po latach obliczeń miała chociaż szanse
wygenerować coś równoważnego z takim kodem. Co do tych metod które
znam obawiam się że sobie nie poradzą.

2. pozwól aby to wolontariusze zdecydowali czy podoba im się twój projekt czy nie

Zrobię raz byle co, sparzą się i potem gdy zrobię coś lepszego nie będą już chcieli?

3. ja osobiście z chęcią liczyłbym projekt taki jak twój, ale a możliwością porównania poszczególnych algorytmów <- ale to twoja decyzja

Właśnie jakbym użył algorytmów które teraz znam i o których wiem że dają jakiś
postęp to by tak ładnie nie wyglądało. Nie mam nawet pomysłu jak efektownie
zaprezentować wyniki. To by było mniej/więcej tak, że zmieniam kilka drobiazgów w
programie, potem około 1 tyg obliczeń na 50-100 komputerach i program gra albo o
0.2% lepiej, albo o 1-2% gorzej. Potem znowu jakaś zmiana, test i tak w kółko.
Program nie byłby "sztucznie inteligentny", tylko sieć obliczeń by pomagała
zweryfikować pomysły programisty, albo by testowała kilka rozwiązań w pobliżu
owych pomysłów.

Fajnie by było wrzucić coś do sieci co by zupełne samo się rozwijało i powiedzmy po
milionie lat obliczeń grałoby jak inne dobre programy.

4. co znaczy: "dobre wyniki"? jeśli chodzi ci o algorytm który będzie grał najlepiej to ok <- ale to też możesz wrzucić do gry kilka algorytmów i na podstawie porównania określić, że dany algorytm jest najlepszy.

Oj oj... to jest tak jak z tą monetą. Algorytm może dać dobry wynik dlatego
że miał szczęście. Każdy algorytm trzeba uruchomić z różnymi parametrami chociaż
10tys razy aby wyrobić sobie pogląd. Zobacz w jaki sposób dobierałem parametry
metody magnetycznej
http://pastebin.com/LL9iJi1n
Ten program był uruchamiany całe dnie z różnymi parametrami dla różnych zarodków
liczb losowych. Po tym miałem mniej/więcej wyrobiony pogląd jaka konfiguracja
jest dobra i używałem takiej samej do szachów.

Ludziom się to spodoba, że widzą różnice między algorytmem A i B <- może nawet ktoś się tym zainteresuje i znajdzie jakieś nowe rozwiązanie tego problemu. W przeciwnym wypadku twój projekt będzie kolejnym, w którym będzie się walczyć o dobrą pozycję :(

Trzeba się dobrze zastanowić.

Pozdrawiam

[goofyx]

To teraz całkowicie nie wiem:
1. o co ci chodzi?
2. co chcesz osiągnąć?
3. jaki masz cel?

Według mnie strasznie to komplikujesz, albo ja jestem za głupi żeby zrozumieć <- z posta na post coraz mniej kapuje co do tego co chciałbyś uzyskać w tym projekcie.
Piszesz, że zmiana parametru w algorytmie i trzeba tydzień obliczeń <- czy to źle?? To byłoby właśnie świetne. Uruchomić X algorytmów dla Y gier z Z ilością różnych parametrów <- a potem zrobić porównania, że X1 przy Y1 najlepiej uczył się dla Z1.
A po za tym co znaczy dla ciebie tydzień obliczeń? Czy to jest 7 dni pracy procesora? Jeśli tak to ja przerabiam na swoich maszynach średnio 15-20 dni pracy CPU w ciągu 24h. Więc twój tydzień obliczeń łykam w kilka godzin. A to tylko ja.
Jeśli będziesz miał w projekcie 1000 komputerów (co na spokojnie jest do osiągnięcia) to będziesz przerabiał ok.600h czasu CPU w ciągu doby <- więc twój tydzień możesz mieć przeliczony w 5-10 minut.


Mógłbyś jasno i zrozumiale (jak dla mnie) napisać w kilku słowach do czego i jak chcesz wykorzystać platformę boinc?
Ja naprawdę nie jestem złośliwy <- ale tak jak pisałem im dłużej czytam ten wątek tym mniej sensu w twoim projekcie boinc widzę.

[goofyx]

sory za drugi post

ps.: ja osobiście chciałbym i myślę nad projektem boinc w którym ten sam problem będę mógł obliczać za pomocą kilku algorytmów (kilku pod projektów) aby w rezultacie mieć porównanie co i w jakich warunkach sprawdza się lepiej lub gorzej.

[legis]

Uczenie polega na tym, że 100 razy dodaję małe losowe wartości
do parametrów i robię turniej.
37.71%
33.12%
33.75%
32.92%
33.33%
32.50%
32.71%
31.25%
30.21%
28.96%
31.25%
30.83%

Nie widać postępu. Program nigdy nie przekroczył początkowego 37.71%. Prawdopodobnie
jest jak mówiłem. Po pierwsze jest za mało gier aby wyłonić silniejszy program, a po drugie
wyłania się ten który dostosował się do specyficznych warunków.

jednego nie kumam jeśli za każdym razem wartości są losowe to jak można sprawdzić czy program się uczy, jeśli zagramy 100 razy a potem raz jeszcze 100 te same partie i kolejny raz 100 tych samych partii to stwierdzimy że program się uczy lub nie jednoznacznie. Przy milionach możliwych rozgrywek za każdym razem innych losowych chyba trudno to stwierdzić.

[mariotti]

To teraz całkowicie nie wiem:
1. o co ci chodzi?
2. co chcesz osiągnąć?
3. jaki masz cel?

Według mnie strasznie to komplikujesz, albo ja jestem za głupi żeby zrozumieć <- z posta na post coraz mniej kapuje co do tego co chciałbyś uzyskać w tym projekcie.
Piszesz, że zmiana parametru w algorytmie i trzeba tydzień obliczeń <- czy to źle?? To byłoby właśnie świetne. Uruchomić X algorytmów dla Y gier z Z ilością różnych parametrów <- a potem zrobić porównania, że X1 przy Y1 najlepiej uczył się dla Z1.
A po za tym co znaczy dla ciebie tydzień obliczeń? Czy to jest 7 dni pracy procesora? Jeśli tak to ja przerabiam na swoich maszynach średnio 15-20 dni pracy CPU w ciągu 24h. Więc twój tydzień obliczeń łykam w kilka godzin. A to tylko ja.
Jeśli będziesz miał w projekcie 1000 komputerów (co na spokojnie jest do osiągnięcia) to będziesz przerabiał ok.600h czasu CPU w ciągu doby <- więc twój tydzień możesz mieć przeliczony w 5-10 minut.


Mógłbyś jasno i zrozumiale (jak dla mnie) napisać w kilku słowach do czego i jak chcesz wykorzystać platformę boinc?
Ja naprawdę nie jestem złośliwy <- ale tak jak pisałem im dłużej czytam ten wątek tym mniej sensu w twoim projekcie boinc widzę.

To wróćmy do podstaw :) Mój cel ma bardzo prosto sformułowany:
1) chcę zrobić mocny program do gry w szachy
2) najlepiej jakby ten program był samouczący.
Cel jest prosto sformułowany, ale strasznie trudny w realizacji.
Trudność ma swoje dwa źródła:
1) po pierwsze trudno jest zaimplementować coś takiego, implementacja
    wymaga czasu, spokoju, opracowania testów czy nie ma błędów, w
    końcu przeportowania na wiele platform - każdy wolontariusz ma inny system i
    procesor.
2) nawet jak w implementację włożę masę pracy, wysiłku, nie popełnię
    żadnych błędów, a wolontariusze będą liczyli przez całe lata to nie
    ma gwarancji na sukcesy.

Jakby program był w pełni samouczący, to moim zdaniem byłaby super
marchewka dla wolontariuszy. Program byłby jak dziecko. Na początku
kompletnie nie umie grać. Potem uczy się i uczy, gra coraz lepiej, aż
w końcu pokonuje wszystkie najlepsze programy na świecie. Można
do tego celu użyć algorytmu genetycznego. Problem w tym że jak
oszacowuję ilość gier potrzebnych do takiego zadania to wychodzi mi
liczba która ma całe miliony cyfr. Bez względu na to co chcę, nie
damy rady czegoś takiego policzyć, nawet jakbyśmy całą galaktykę
przerobili na procesory - chociaż nie wiem co jest w czarnych dziurach ;-)

Są dwie inne możliwości. Pierwsza taka aby zastanowić się nad
lepszym algorytmem niż genetyczny, takim żeby wymagał mniej
gier, a miał podobny potencjał. Druga możliwość jest taka aby
użyć szybszego algorytmu, ale o znacznych ograniczeniach. Obecnie
pracuję/myślę nad jedną i drugą możliwością.

Przykładowo mam taki pomysł na zmniejszenie ilości gier.
1) Bierzemy jakiś program.
2) Mutujemy go tak jak w algorytmie genetycznym, więc mamy już dwa programy.
3) Z programów całkowicie usuwamy czynnik losowy, czyli choćby zagrały
    milion gier to każda będzie wyglądała tak samo.
4) Bierzemy np. 100 'losowych' układów i gramy 200 gier, tak że z tego
    samego układu gramy dwie gry, raz zaczyna jeden program, drugi raz
    drugi.

Pomysł wydaje się genialny, ma same zalety:
1) Dzięki temu że usunęliśmy losowość z programów, nie mamy problemu z dokładnym
    pomiarem siły gry. Nie ma zaburzeń losowych, więc niby nie trzeba rozgrywać milionów gier
    w celu uzyskania dokładnego wyniku.
2) Dzięki temu że programy grają dwa razy z tego samego układu, to przed każdym
    stoi zadanie na identycznym poziomie trudności, nie ma niczego co by sztucznie
    wpływało na korzyść jednego z programu
3) Dzięki temu że użyliśmy 100 'losowych' układów unikamy dostosowania programu
    do gry w jakiś specyficznych warunkach, program gra różnorodne gry, tak jakby
   był czynnik losowy.
Gdy to obmyśliłem to przeżyłem wręcz uniesienie :) Ale niestety praktyka pokazuje co
innego. Teoretycznie wydaje się że wszystko zostało dopracowane, ale w praktyce po
takim uczeniu program wcale nie robi postępów. Zastanawiam co jest powodem problemów,
niby pomysł jest dobry, a jednak nie działa.  Prawdopodobnie program nauczył się grać tylko w
jakiś konkretnych warunkach, a ogólnie gra nawet gorzej.

Nie chcę takich niedopracowanych pomysłów wrzucać do sieci, to jest i problem dla mnie i
dla wolontariuszy. Dla mnie to wymaga kilkadziesiąt albo kilkaset godzin pracy nad
implementacją, a dla wolontariuszy poświęcenia komputerów. Trzeba zrobić coś co będzie
dawało sensowne wyniki.

Pozdrawiam