Hello Don, Nick, Magnus, I here answer the 3 previous emails.
2007/3/18, Don Dailey <[EMAIL PROTECTED]>:
Another possible candidate is Mogo, running at 3K play-outs, like the version running on CGOS right now.
I thought about that, the good thing is the resources taken (between 0.6 and 0.3 s per move), the problem is this limited version MoGo seems to be too much "intransitive".
Do you think any version of gnugo is suitable as an anchor?
I think gnugo is a very good anchor and very difficult to overfit. It is good that ggexp is always playing. Last version of gnugo would also be good. As Magnus said, gnugo is maybe too deterministic, but this is only an issue if someone try to "cheat" by creating an winning opening against gnugo (I managed to find an opening which makes 100% against gnugo). I don't believe it is a practical issue then.
On Sat, 2007-03-17 at 18:45 -0500, Nick Apperson wrote: > one concern i have is that within a family of programs (such as MC) > the estimated skill differences are overestimated. I would really > like to see an anchor that uses a different technique. I'm not > offering a solution. Thoughts? One idea is to measure this phenomenon to see how much we should be concerned by it.
You are right. And the results you have so far in addition with the results in cgos can assess if it is wrong or right. I agree it is bad to have only MC programs running on cgos, but do we have a program > 2000 ELO which is not MC? Maybe a "solution" would be to take gnugo for example, and give it an advantage to make it at 2000 ELO (handicap or komi). This would however don't measure the level of a program against a strong one, but the ability of a program to catch up on a lost game. There is also the perspective of the 13x13 and 19x19 servers where (1) gnugo will be much stronger, (2) we can have easily handicaps. Sylvain _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
