[computer-go] Anchor player

[Don Dailey]

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