[computer-go] Anchor player

[William M. Shubert]

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.

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.

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/
>