Hi Sylvain, I think what you are looking isn't a strong Anchor player, but strong players who are always available.
However, I do want to upgrade the Anchor player too, perhaps putting up 2 Anchors. I will prepare a version of Lazarus - it will take a few days. I'm not sure what my goal rating is - I want it to play as strong as possible but still capable of being set up to run on modest computing systems. So I will have to experiment. I think it will easily be at least 1800 - perhaps as strong as 1900. You will of course need opponents who are as strong as possible in order to get accurate ratings. Unfortunately, you seem to have a monopoly on the strong programs! I haven't seen anything yet get beyond 2100 or so except versions of Mogo - which go all the way to well over 2400 assuming the ratings are relatively accurate. However, I'm sure that strong programs will follow. Meanwhile, Lazarus will be on and off - I'll try to keep it mostly on. I think there are at least 2 or 3 other programs in the same range that are not playing. Perhaps they will come back, perhaps with improvements. I think some of these programs are stronger than Lazarus, it's just that they are running on less hardware. Lazarus is running on a core 2 duo 6700 and it benefits from thinking on the opponents time. Some of these other programs are running on much slower pentiums and still approaching similar levels (without pondering.) Yes, all that stuff helps. - Don On Sun, 2007-03-18 at 15:10 +0100, Sylvain Gelly wrote: > 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/
