> "(compressed) bitmaps". You don't just keep a sorted list? With (compressd) I mean that (most of) the bitmaps are relatively sparse. For an isolated stone, the needed size only needs to be about ((2*19) +1) / sizeof(bitmap_element), ~= 2 or 3 32bit ints. By skipping the leading and trailing zeros, you can speed up operations on the bitmaps. The problem with bitmaps is that iterating over them is quite costly. (the advantage is that set/get is very cheap)
Sorted lists need to be resorted on every addition/merge. Linked lists are cumbersome for liberties, because a liberty can be a part of more than one list. (dynamic allocation is out of the question here, IMHO) The best quality of bitmaps is that you don't have to worry about duplicates. This duplicate-checking is where all this pseudo-liberties -talk is all about. (that is: trying to avoid it) Merging two (or more)This duplicate-checking is where all this pseudo-liberties -talk is all about. (that is: trying to avoid it) Merging two (or more) chains is extremely easy with bitmaps: merge (== OR) their members, merge (== OR) their liberties. simple comme bonjour! Splitting chains is a bit more difficult, but that will never happen. (without undo, that is) Adriaan van Kessel _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
