On Thu, 2007-02-08 at 15:58 -0800, steve uurtamo wrote: > > > > tranforms as the "cannonical" key. In most cases 8 positions will > > > > > > IIRC, choosing the smallest may cause some unwanted effects. Not sure... > > > > It's not quite as good as using 64 bits free and clear because there is > > compression towards the lower bits. > > i must be missing something here -- the whole point of canonicalization is > that you want to be able to recognize a 'book line' when it appears, even if > you have to rotate and/or reflect your board in order to match the book line, > right? you save 8x the space by only stashing one copy of the book line, > and by using some canonical version of the hash key and doing 8 transforms > on every board position when the game move is less than the longest known > line length, or somesuch.
Yes. But Don's confusion was independent of the canonicalization, though it was probably caused by it. > > if you're only storing a few hundred lines, or a few thousand, why not store > all 8 copies? then it's just a lookup with no extra transforms. > Sure. It is just an engineering decision: do you want to waste the RAM-space, or only the CPU-time. For a few hundred records, optimising for space is probably not worth the effort. For a larger fuseki / joseki /pattern book, it probably is. CPU is cheaper than RAM, and a cache miss is worth tens of instructions. It depends. (though "travel light" is always a good adagium, see David Fotlands hilarious compression of a joseki library into 12 bits/move, IIRC ;-) BTW: once you choose the /8 gain by implementing canonicalization, you'll probably want to implement /2 color-swaps, too. (but this will only be profitable for libraries, not for 'history' such as in Don's case.) HTH, AvK _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
