Re: transposition table

[Jeremy Thorpe <jthorpe@xxxxxxxxxxxx>]

Serge,

there can never be a perfect solution to this problem if you want to
account for super-ko, short of recording and hashing the entire game
history.  here's why:  

there are plenty of reversible moves (even ones other than ko), so you can
construct a game that goes any number of moves before (potentially)
repeating, let's just say 10.  now, it's not only on the tenth move (when
your move is restricted) that you have to start considering the
implications of super-ko, you may want to have considered super-ko on,
say, move 5.

so, if you want a theoretically correct solution, it is not enough to
simply note all of the moves that will be restricted on the next move, but
all of the moves that might be restricted down the road.  it seems to me
that the best way of specifying that is to record all of the positions
ever played in a game.  and it seems that that is not a good solution at
all.

my solution?  i've played damn close to 1000 games on igs and never run
into a super-ko situation myself (though i did see one once--it was quite
a big deal).  so just make a flag for ko.  of course, you have to specify
where the ko is (on many boards there will be several possibilities),
which you can easily do by noting the last move, or the restricted move.
the restricted one may be simpler.

also note that it may take a long time to find all possibly restricted
moves (on just the next move) by applying super-ko (how far back in the
game do you look). think if you want to actually do this process for every
move.

there, 2 cents even.

see yah!

-jeremy

On Thu, 22 Oct 1998, Serge Boisse STNA 7P (33) 562 14 5731 wrote:

> This works fine as long as  (super) Ko is not relevant for the position, (I
> notice a great speed improvement), but  when Ko or super Ko is relevant, there
> are several positions which are the same (thus same hash), but whose best moves
> are not the same.
> So I tried to use a couple (hash, move Number) as the Key for the hashtable I
> use as transposition table.
> It appears that it solves only a part of the problem :
> 
> How could a transpositon table handle such a tricky situation ?
> 
> Help !!