Re: computer-go: Languages for programming go are?

["Phil" <PhilippGarcia@xxxxxxxx>]

Thanks Don & Anders!

After reviewing my random game test algorithm, I must state that is
shouldn't be used as a benchmark (my mistake). It's main purpose was to find
bugs. It works by generating completely random moves and attempting to play
them. An illegal move is turned into pass (12% of all moves). This,
unfortunately, inflates the performance figures. So that we can compare
apples to apples, can anyone propose a benchmark algorithm?

Phil

----- Original Message -----
From: "Don Dailey" <drd@xxxxxxxxxxxxxxxxx>
To: <computer-go@xxxxxxxxxxxxxxxxx>
Sent: Tuesday, January 02, 2001 9:37 AM
Subject: Re: computer-go: Languages for programming go are?


>
>    From: "Anders Kierulf" <anders@xxxxxxxxxxxxxxxxx>
>
>    > Anyway, I'm curious about what other knowledge is incrementally
updated
>    > by my fellow Go programmers, and how, if you don't mind.
>
>    SmartGo currently keeps the following information up-to-date:
>    - Number of black and white stones on the board.
>    - Zobrist hash code (64 bits).
>    - Number of empty neighbors for each point.
>    - The stones in each block (in a circular linked list).
>    - The anchor (smallest stone in a block) of each stone.
>    - The liberties and liberty count of each block (in an array).
>    - (Optional) Bitboards for all black, white, and empty points.
>
>    > Just for some sporty fun, my Go program on PIII-500 can execute about
>    > one million random moves in under 5 seconds:
>    >
>    > Board::TimingTests()
>    > ---> Playing Random Game
>    > ***> 1000000 Turns
>    > ***> 4.625 seconds.
>    > ***> 216216 turns per second.
>
>    Can you elaborate on what you mean by playing random games? To make it
a
>    more realistic test, it should probably include taking back the moves
>    played, and also check some random liberty counts and iterate through
>    liberties between moves.
>
>    Anders Kierulf
>    www.smartgo.com
>
>
> Are these numbers based on taking back moves or just making them?
>
> I would like to emphasize that my test  does both.  Even though taking
> back moves is free for me,  I presumably pay for this  up front with a
> slower move maker.   (Actually, is my move  maker really slower?   I'm
> not convinced of   this  because every   program  has to  provide   an
> equivalent mechanism  and extra logic for taking  back moves.)
>
> I get 300,000 nodes per second, on a pentium II  laptop running at 400
> MGH which includes evaluation,  which is  fast  and simple, but  by no
> means free.
>
> Phil's program  is  doing some  work mine does  not do,  because he is
> keeping some  bit boards  updated too.   So it's  hard to construct an
> apples to apples test unless he can  turn that stuff  off.  I have yet
> to see a good   reason to turn   my program into  a hackery  of global
> variables that are updated  in place, but I would  do this if it meant
> extra speed.  I don't know of a fair way to test this without actually
> going through this excercise, but I  need a lot of motivation, because
> I think my program is at least pretty fast, if nothing else.
>
>
> Don
>