RE: computer-go: transpositions (less unclear?)

[Jean-Pierre Vesinet <jpvesinet@xxxxxxxxxx>]

Mikael Thulin wrote:
> > I am not even sure whether
> > this case exists (a situation that can be reached by 
> > two different move
> > sequences from a starting situation, and having two
> > different values because of superko).
> 
> I'm not sure what case you are looking for but I think 
> that my post "Hashcoding under the super-ko rule" shows 
> such a position. Does it?

You did not give an example of such a case. I would very much like to see
one. Your example, just as mine in the previous post is an example of a
crucial move, prevented by the superko rule.
Let me explain again. The same situation "A" must be reached by two
different move sequences starting from the same position "S" (not
transpositions, this move sequence is NOT a cycle) AND have a different
value BECAUSE of superko. That seems difficult to construct. It may even be
impossible...

Maybe I am not clear.

Here is a little schema:

Starting situation "S" ------------alternate play--------------> Situation
"A"

Starting situation "S" -------different alternate play---------> Situation
"A"

The two situations "A" are identical, but their minmax value is not, because
of different move history and superko.

I believe this case is either impossible or extremely unlikely. So maybe we
don't need to worry about it?

> > What happens if, during the search, you come upon an 
> already evaluated
> > situation whose flag is not set (different line of play)?
> 
> How do you mean that the situation is the same.
> Just board layout and player at move? illegal moves included?
> set of previous positions included?
No, only board layout and next player are repeated.

> I think the solution for my program is to extend the 
> evaluation from "true and false"
> to "true, false and unknown" and assign unknown to the 
> cyclic-positions.
If you mean recompute the value of the situation each time it is found
during the search, it would slow down enormously the search (without
necessity in most if not all cases).

> (I know that Thomas Wolf's GoTools only use true and false as values
> for that reason)
GoTools does not look for the best move sequence in actual play: it only
finds the stone-killing or stone-saving sequence, regardless of the score.
This explains why GoTools does not recognize seki, for instance.

Regards,

Jean-Pierre