RE: computer-go: hascoding under the super-ko rule

[Jean-Pierre Vesinet <jpvesinet@xxxxxxxxxx>]

> Could you please explain the differens between "positional 
> super-ko" and "situational super- ko"?

Positional superko forbids the repetition of a whole board position (i.e.
exactly the same stones on the same points, regardless of symmetry or
rotation).

Situational superko forbids the repetition of the same situation (i.e. the
same position AND the same player).

Japanese rules use neither. But if neither player yields, the game ends in
"no result". Chinese rules are not too clear about the particular superko
rule used. The game may even be drawn or replayed if the referee decides so
!

You have to choose which superko rule your solver will use.

> 
> > Similar problems can be constructed for situational superko.
> Please give an example?
>

A move forbidden by SSK is also forbidden by PSK. For example, this nice
4-move cycle I just made up:

  |. . . . . . .
  |. . . . . . .
7 |O O O . . . .
6 |X X O . . . .  Lower left corner of the board.
5 |. X O . . . .  Outer stones alive.
4 |X X O X X . .  Black (X) to play.
3 |O X X O X . .
2 |. O O O X . .
1 |. O . O X . .
  +-------------
   A B C D E

(;SZ[13]AB[bk][ck][bj][bi][bh][aj][em][el][ek][ej][dj][ah]AW[bg][ag][cg][ch]
[ci][cj][dk][dl][cl][bl][bm][dm][ak]PL[B]C[Outer stones alive.
Black to play.
By situational superko, White is dead.
By Japanese rules, Black can get a "no result" or a seki.]
;B[al];W[];B[am]C[Now White cannot capture because it would recreate the
same situation as the initial one.];W[];B[cm])

Not being an expert on Japanese rules, I will cross-post this position to
the go rules mailing list for comments.

------

About the hashcoding issue, I would be very interested if you could explain
in a few words how your hashtable manages big problems. One big problem with
tsumego solvers is the huge size of the search space in go. The number of
nodes quickly reaches several million nodes, even for average sized problems
(15-20 points of playing-space). For example GoTools, Thomas Wolf's
excellent solver uses a hashtable of fixed size (maximum = 65535 entries).
The solving speed is incredibly fast for small problems, but slows too much
on bigger problems.
Is your hashtable size adaptative? Do you increase it until it explodes ? Do
you drop the oldest positions to make room for newer ones ?

Regards,
Jean-Pierre