Jason House wrote: > > > On Dec 19, 2007 10:44 AM, Don Dailey <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > I actually have a routine in Lazarus that rotates a full board. It's > called transformBoard() and it takes 2 arguments - a board to > rotate and > a transformation (0 through 7) and returns a new rotated board. > > I don't use it much except for debugging or stuff done at the root, > because there are faster ways to do things. > > I also have a routine called canHash() which returns a canonical hash > of the board by trying all 8 transformations and returning the lowest > valued one. It is more efficient (but not efficient) because it > doesn't actually produce a new board - it just builds 8 hashes of the > board from scratch without touching anything. This routine is only > used at the root for storing opening book moves. > > You can use zobrist hashing for maintaining all 8 keys incrementally, > but you probably need a fairly good reason to do so. Incrementally > updating of 1 key is almost free, but 8 might be noticeable if you > are > doing it inside a tree search or play-outs. It depends on how > "fat" or > "lean" your program is. Even 8 keys may not be noticeable if your > program does a lot of work at each move (or an end nodes.) If > you are > not, then it doesn't really matter how you do it. > > > It's also possible to select hash keys such that transformations of > the board's key is the same as recomputing the key for a symmetrical > board position. This will be *much* faster. I came up with a scheme > to do this and documented it on my website, but haven't actually > implemented it yet. Are you talking about building the random table in such as way that the hash comes out the same? The only thing I can think of is to make each canonical point have the same random numbers, for instance the 4 corners would have the same code. But I don't think that works - having exactly 2 corners would cancel and come to the same hash as an empty board.
I will look at your page - it would be interesting if there are schemes for maintaining a single Zobrist hash without having incrementally keeping 8 different hashes, but if there is I would like to learn about about it. - Don > > While it was interesting, I just couldn't come up with any uses for it > beyond fuseki and games of mirror go. While that was appealing, it > would slow down the program and it added a layer of complexity that > would either make debugging tougher or require tossing cached search > data when the opponent plays a symmetric move. > ------------------------------------------------------------------------ > > _______________________________________________ > 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/
