I remember seeing a paper or something on this a good while back. If I remember correctly, it is possible to legitimately criticize both types of superko based on some obscure corner cases that are possible. I don't remember the details and I'm certainly no expert.
- Don On Tue, 2009-04-14 at 12:33 -0700, Ian Osgood wrote: > On Apr 14, 2009, at 11:06 AM, Robert Jasiek wrote: > > > To offer an on-topic reason: positional superko requires less storage > > and execution time than situational superko. > > > > -- > > robert jasiek > > Really? > > Go programs already store side-to-move as part of the board state. > For ko detection, you usually use a Zobrist hash, which merely gets a > side-to-move hash XORed into it for situational ko, so no storage > increase. > > Situational ko detection is actually faster, because you only need to > check every other position in history instead of every position. > (But honestly, it makes little difference since you are already only > going to look at positions with matching stone counts.) > > The practical answer for program authors is to support both of these > ko rulesets, since they are both widely used in the Go world. > > _______________________________________________ > computer-go mailing list > [email protected] > http://www.computer-go.org/mailman/listinfo/computer-go/
_______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
