[computer-go] ego110_allfirst on CGOS

[Don Dailey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The results look more reasonable now,  11/11 usually indicates a clear
superiority.

Still a 70 ELO superiority of housebot but that is within a believable
range, it could turn around if we give then enough time.


>> How many all-as-first moves are you considering?
> 
> 7/8 of the moves until the end of the simulated game.  This will vary
> from random sim to random sim if the game lengths are different.  It
> also uses passes as part of the game length calculation.  A result of 0
> moves is replaced with 1 move.  Out of that list, only moves for the
> color to play are considered, and only if the opponent didn't play in
> that spot first.
> 
> 
>> What are the possible
>> differences?
>>
>>   1. eye rule
> 
> I thought we beat this one to death.  It's an eye if all 4 neighbors
> match the color to play (or are off the board), and one of the following
> are true:
> 1. It's a corner and the diagonal position is not an enemy stone
> 2. It's an edge and neither of the diagonal positions are an enemy stone
> 3. It's in the center and no more than one of the diagonal positions are
> an enemy stone
> 
>>   2. number of all-as-first moves  (7/8 for me + 1)
> 
> Explained above, but I realize I got one small detail wrong.  It's
> max(1, min(1000,7/8*moves))

I think mine comes down to that in 99.99% of the cases.



>>   3. quality of RNG
> 
> Mersenne Twister (generic implementation available free online)

Same as AnchorMan


>>   4. correctness of random move selection strategy.
> 
> Pick a random empty position.  If illegal or eye-filling, remove from
> consideration the list and repeat.

Same basic idea.   I start by taking all filled points and removing them
from consider but I reinitialize after a capture.

>>   5. depth at which you stop a game.  (about 1000 moves for me.)
> 
> I never stop a game.  They always play out to the end.  I put an upper
> bound of 1000 on the moves to keep for AMAF, but the random game will
> continue until it's completed.
> 
>>   6. stopping rule.  (both program have no non-eye filling moves.)
> 
> I use that same rule.  If a program hits that condition, it's forced to
> pass.  Play then continues until there's two passes in a row.  Each pass
> is considered a move for purposes of AMAF counting.

Exactly the same for me.



>> I just thought of something.   I think I initialize the statistics array
>> with 1 draw per move as a cheesy way to avoid divide by zero error.
>> Could this be affecting the performance?   Perhaps at low levels like
>> this it has a noticeable effect?    Would it make the program especially
>> vulnerable to an identical program that doesn't do this?
> 
> Draw?  Is that a valid outcome of your random simulations?  I would
> assume your counters would be integers (and a draw value of 1/2 wouldn't
> work).

A win is 1 and a loss is -1  so I set all the game counters to 1 - which
is like a draw.   Of course in the simulations a draw can never happen.


> 
> Curiously enough, you found a potential bug in my amaf implementation.
> Divide by zero could occur (but doesn't seem to)
> 
> Also, we may differ on our handling of ko.  I use simple ko rules in my
> playouts.  I think that differs from other implementations that don't
> use ko rules at all.  I don't use any super ko logic anywhere in my bot
> at the moment.

I use only simply ko in the simulations.  But outside the simulation I
honor positional superko - so AnchorMan will never make an illegal move
due to this.   It's rare but some even some good bots don't do this and
will lose a game once in a great while.  It's probably worth less than
15 ELO to do this right.   But that does mean GenAnchor_1k should be
slightly stronger even though it doesn't appear that way now.

- - Don



> _______________________________________________
> computer-go mailing list
> computer-go at computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG/9HBDsOllbwnSikRAiQcAJ4h0kG+9iRvZSxwTBRnArYvRxrPQACg1PyM
LrePa5fuhOXM/ChZbc/VYgA=
=quAK
-----END PGP SIGNATURE-----