Re: [computer-go] Data structures for Go

[A van Kessel <Adriaan.van.Kessel@xxxxxxx>]

The real risk is not in undoing but in *not* undoing, IMO.
If you have a "course undo" approach (eg just popping the
whole board) you should at least invalidate all the data
that depends on the boardstate.
If the program has any notion of chains or liberties,
it should either maintain them incrementally (including
undo) , or they should be recalculated at the moment
you need them (partial floodfill) or when it pops
the boardstate (wholeboard floodfill).
Which causes you to perform twice as many floodfills
as in in the "undo" case.

Keeping as little state as possible is a good thing.
Storing it in a hash/cache-table is one way of avoiding
the "forgot to undo" errors: if the board configuration
changes, the data will become unreacheable.

For my own toy project, "goto" I have a combined
undo/redo structure. I found out that it's data
can be valuable in ... debugging: they allow me
to inspect the steps the program took, in a very
compact form.

AvK
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://computer-go.org/mailman/listinfo/computer-go