[computer-go] Anchor player

[Don Dailey]

On Wed, 2006-09-27 at 00:29 -0700, William M. Shubert wrote:
> Why do you need to have only one anchor?
> 
> On KGS we can have any number of anchors, and the more anchors, the more
> stable the system is as a whole.

I am using ELO ratings but I think your suggestion would work with ELO
just as well and I like it, it's something I will definitely consider.

My previous reason was that I didn't want to fix the rating of more than
1 player, but your solution is simple,  just average the "anchors"
together and fix this average point.

> The only difficulty is that anchors are no longer truly fixed. Instead,
> you fix the average of the anchors. So if you set anchors at rating 1.0
> and 2.0, and the rank computation determines that they are 1/2 stone
> apart, you set them actually to 1.25 and 1.75, then put the other rated
> accounts appropriately.
> 
> It works very well. I think in computer go, it would be even more
> important, because if you can anchor several different algorithms, then
> competitors who are good only against one particular opponent won't get
> as much of a rating boost.

I'll think about this.  My original intent was to have a highly
standardized well understood single reference point.  20 years from now
that player could be "brought back to life" as a way to compare rating
drift over the years and to have a clear metric for measuring computer
Go progress.

A single player is more easily managed too, so there are pro's and con's
to having multiple anchors.   Many players are "fragile" in the sense
that they don't play variety, may be proprietary programs and may even
become obsolete or get little upgrades from time to time.   I am rather
interested in not allowing drift, even over a period of years which
would happen with multiple anchors that changed over the years.

But the idea is quite nice and has many advantages too.  I will
definitely consider doing this.

- Don



> On Tue, 2006-09-26 at 13:30 -0400, Don Dailey wrote:
> > I'm giving some thought now to which program will be the anchor player
> > on the new CGOS.   I would like the Anchor player to have the following
> > characteristics:
> > 
> > 
> >     1.  Non-deterministic  - it should not play predictable moves 
> >         including the opening phase.
> > 
> >     2.  Open source.   The code should be accessible by all.
> > 
> >     3.  Fixed.  It should have a fixed level that is not dependent on
> >         time or the performance of the machine it is running on.
> > 
> >     4.  Scalable.  For the future it would be nice to be able to use
> >         the same player set to a higher level.
> > 
> >     5.  Written in C.
> > 
> >     6.  Very low resource usage.
> > 
> >     7.  At least as strong as AnchorMan.   I'm thinking it makes sense
> >         that it shouldn't be too close to the top either.  Since it is
> >         being used as an Anchor it should be relatively close to the
> >         median player on CGOS to benefit from the widest variety of 
> >         opponents and to function best as an Anchor player.  I would
> >         still prefer it to be well above the median in order to
> >         cater more to the stronger players.
> > 
> > I consider the scalability to be the least important feature and low
> > resource usage to be one of the most important issues, since the Anchor
> > will probably be running on the server machine.   It's also useful as an
> > experimental tool to be low resource.
> > 
> > AnchorMan has many of these features but is not open source or scalable.
> > However it's currently the top choice, it's very low resource being
> > designed for PDA's and it runs on the server machine itself.   But I
> > think we can do better.
> > 
> > It would be ideal, but not required, if we could publish the playing
> > algorithm in a way that it could be duplicated in a precise way by any
> > researcher.  We basically did this with the Generic Monte Carlo player.
> > Many people produced equivalent clones of the Generic Monte Carlo player
> > but I had the sense there were little minor differences because we would
> > get reports like, "It's pretty much the same EXCEPT for this one little
> > thing ..."
> > 
> > I would prefer it to be written in C for two reasons:  
> >  
> >    1. Very low computer resource usage and no run-time or language
> >       interpreter required.   Memory management issues not a big 
> >       concern. 
> > 
> >    2. Lowest common denominator.  C compilers are everywhere on every
> >       machine freely available.  Probably the most known language.
> > 
> > My thinking is that if someone is willing to donate code and make it
> > open source, I can publish it on the CGOS site and it can be the Anchor
> > player, especially if it has all the important characteristics.
> > 
> > If I don't get any volunteers, I will produce a player myself and fully
> > advertise the source code and algorithm.   Ideally I would prefer a
> > miniature open source project with the above goal and a limited
> > lifetime, just enough to produce a strong player that doesn't consume
> > much resource (plays fast) and is easily describable.     
> > 
> > Such a player could serve as a useful standard for computer GO for years
> > to come,  especially if the playing algorithm were published.  Even when
> > programs advance way beyond the playing level of our reference program,
> > it would alway be a historic entity that was well understood and could
> > be used to extrapolate performances of programs from different times.
> > 
> > Any thoughts?
> > 
> > - Don
> > 
> > 
> > 
> >  
> > 
> > 
> > _______________________________________________
> > computer-go mailing list
> > computer-go at computer-go.org
> > http://www.computer-go.org/mailman/listinfo/computer-go/
> > 
>