I wrote: > Gunnar wrote: > > Arend wrote: > > > About the first: We could instead automatically reset komaster > > > to EMPTY in do_trymove() when a ko is resolved (and remove the above > > > code from komaster_trymove()). I am not sure what is best here. > > > > This is also what Martin does. But is there actually any need for an > > automatic reset? It seems to me that this check could be done in > > komaster_trymove() after doing the move and that it's only meaningful > > for non-ko moves. > > In fact, it seems outright wrong to me in the case of ko moves: we don't > want to reset the komaster in case of a two stage ko. (This may still > happen with your patch further down the search tree, I think.)
I think I was confused here, as Gunnar pointed out to me. In the case of a two stage ko, the code in komaster_trymove moves the kom_pos to the position of the second ko, when we capture it (while we are komaster for the first ko). My conclusion is now: 1. I think Martin's patch is wrong on this point, as it does the check before komaster_trymove had a chance to update the ko position (this should also explain the increase in reading nodes). 2. I guess we should use Gunnar's latest patch. To be pedantic, it may not be entirely correct in situation such as this (white to move is komaster for *): A B C D E F G H J 19 . . . . . . . . . 18 . . X X O . . . . 17 . . X O * O . . . 16 . . . X O . . . . 15 . . X O X . . . . 14 . . X O . . . . . 13 . . . . . . . . . Capturing D16 doesnt resolve the ko for all eternity if Black blocks at B16 and later recaptures D16. (But the code was probably never correct for this situation.) Arend _______________________________________________ gnugo-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnugo-devel
