Re: [computer-go] Fwd: [gnugo-devel] (GNU) Open source real time Go server
On 1/18/10 3:02 AM, Wolfgang Krames wrote: Hi Benjamin Teuber from Germany works for IGS to make the official client more attractive to western players, e.g. he plans to add a kgs-like-review-tool. You can tell him your wishes (like making igs usable for near blind people) and if possible he will add them to glgo in the future. Wolfgang Krames Good news about the client. Does anyone know what became of Teuber's UGS project? (the one mentioned at Sensei's) Michael ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Open source real time Go server
Hi 1. Just a small precision first: Ingo Althöfer wrote: > Terry McIntyre wrote: > > ... My pet peeve is the KGS "score estimator", which is often wildly > wrong > As explained by others a "strong SE for ALL positions" is equivalent > to a strong program. This is only true if you replace the word “strong” by “perfect”. It is trivial, that a perfect evaluation function gives a perfect player using a 1-ply search, but that is not true for strong evaluation functions. Converting a strong evaluation function into a strong program is still a hard problem. “Almost” good moves are frequently worse than random moves. (E.g. a move that “almost saves” a group that cannot be saved or “almost kills” a group that cannot be killed gives one prisoner to the opponent and wastes one turn. This is worse than pass while random moves are with a high probability better than pass.) 2. Now my proposal: An MC based SE (Score Estimator). Use a strong MCTS program unmodified, except in a small detail to collect data about by how many points each simulation is won. Play a feasible number of simulations like 20K. Build the distribution of the result (= The histogram counting how many wins were found by each result). Otherwise, let the program follow the tree as it does unmodified. In this distribution find the 3 quartiles (the komi shift that produces Q1 25%-75%, Q2 50%-50% and Q3 75%-25% wins for each). If IQR (Interquartile range) = Q3-Q1 > some threshold (say 25 points) output: Q2 as “B+3.5 with large error margin” else output: Q2 + IQR as “B+3.5 IQR(W+1.5, B+11.5)” This would be a state of the art SE and the number of simulations could also be a parameter controlled by the user to adapt the precision to his hardware and patience. After all, it is easier to get a SE from a strong program than the other way round ;-) Jacques. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Open source real time Go server
Hi! On Wed, Jan 20, 2010 at 09:39:31PM +, Jacques Basaldúa wrote: > > As explained by others a "strong SE for ALL positions" is equivalent > > to a strong program. > > This is only true if you replace the word “strong” by “perfect”. It is > trivial, that a perfect evaluation function gives a perfect player using > a 1-ply search, but that is not true for strong evaluation functions. > Converting a strong evaluation function into a strong program is still > a hard problem. “Almost” good moves are frequently worse than random > moves. (E.g. a move that “almost saves” a group that cannot be saved > or “almost kills” a group that cannot be killed gives one prisoner to > the opponent and wastes one turn. This is worse than pass while random > moves are with a high probability better than pass.) This seems like not very productive line of argumentation unless preceded with more exact definitions of strong. > 2. Now my proposal: An MC based SE (Score Estimator). > > Use a strong MCTS program unmodified, except in a small detail to collect > data about by how many points each simulation is won. ..snip.. Actually, there is a thread about exactly this on fuego-devel going on right now; someone wants to use `final_status_list dead` in the middle of game and is surprised about bogus results from Fuego. As has been noted by Martin Mueller: > This said, note that the main strength of Monte-Carlo searches comes not > from accurate scoring, but from comparing the relative success of moves. > E.g. if there is a systematic bias in the evaluation, the scores can be > quite terrible, but often the program can still produce a reasonable > move, since most scores are off by roughly the same amount. Jacques wrote: > After all, it is easier to get a SE from a strong program than the other > way round ;-) That's not entirely clear. ;-) -- Petr "Pasky" Baudis A lot of people have my books on their bookshelves. That's the problem, they need to read them. -- Don Knuth ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
