Re: [gnugo-devel] twogtp_1_32.1

[Daniel Bump]

> > (1) We still get different moves from play_gmp.
> 
> Can you clarify this? What is different from what?

If you use -r to specify random seeds you should get the
same game whether running twogtp or gmp via CGoban. You don't.

> > (The alternative would be to consult the time to get a new seed.)
> 
> Consulting time to get a new seed would not be a good solution. It
> makes it difficult to reproduce a behaviour which depends on multiple
> games (e.g. persistent cache effects, improperly initialized data
> structures).

I agree that consulting time to get a new seed is not good.

> > The first game will then be the game of the crash.
> 
> This doesn't seem to take multigame dependencies into account.

I did test this and was able to reproduce games. I didn't
test it enough to be confident that games are consistently
reproducible.

Intergame effects are obviously undesirable. Do they exist?

Persistent cache effects in this particular context should
be rare to nonexistent since the position at the end of the
previous game does not resemble the position at the
beginning of the new game.

If games are not reproducible in this way, we could have a
problem with very long twogtp runs. Right now I'm
generating 500 games. If I get a crash hopefully we can
reproduce it by loading the game. If not, it could be
a persistent cache effect and we can debug it by
restarting twogtp. That is the aim of this patch.

> This analysis is wrong. In fact the random numbers used in hash.c has
> no effect on the random number sequence what so ever, thanks to this
> construction: 

                 ...

> The place that does consume random numbers is clear_move_reasons(),
> called from reset_engine().

I suppose you are right about this.

> > (2) After this patch, twogtp no longer works with GNU Go 3.0.
> 
> That's a serious drawback and neither would it work with most other

My message made it clear that this can be fixed and I didn't
propose using the patch before fixing 3.0 operation.

> engines. Actually I don't like this solution conceptually at all. I
> suggest the following alternative approach:
> 
> 1. The random number generator is reseeded at the start of
> reset_engine(), using the current value of random_seed. This generally
> improves reproducability of moves, as discussed earlier on the list.
> 
> 2. To avoid playing the same game over and over again with current
> versions of twogtp, random_seed is updated in gtp_boardsize() when
> called for a non-empty board.
> 
> 3. A similar update of random_seed is done in play_ascii(). (Are there
> any more interfaces allowing multiple games?)
> 
> 4. No update of random seed in twogtp.

Hopefully this will work. I am revising the patch and will
try to use this approach.

Dan