2007/3/18, Don Dailey <[EMAIL PROTECTED]>:
I'm not so sure we need to have a really strong Anchor. The Anchor's role is to prevent rating drift over the long term.
You are right about this Anchor's role. However, to be able to accurately rate players, there is a need of opponents not too far from their strength. Of course there are already quite a lot of players on cgos, but they are not always connected, it is why I suggested the add of an strong "anchor" (maybe here the name is badly chosen), always connected.
I could also put together a fixed version of Lazarus. Not the 2100 strength version but a version playing at a fixed level that would play the same strength on any computer. I could not run it on the server and I could not run it all the time from my home, but me might let 2 or 3 people run clones as Anchors.
I think it would not too difficult to find volunteers to run it. For the next few months, I am sure I can find some computer with some CPU time for that. Sylvain
- Don On Sun, 2007-03-18 at 13:09 +0100, Sylvain Gelly wrote: > 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/ _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
_______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
