Author: Vincent Diepeveen
Date: 17:34:32 02/01/01
Go up one level in this thread
On February 01, 2001 at 12:54:53, José Carlos wrote: >[snip] > >>>So what algorithm do you suggest for indexing the table? >>>I mean, it's possible to store the full position representation in (at most) >>>64 bits, as you described; but given an hash table size << 2^64 entries, >>>how to compute the index where any given position has to be stored? >> >>there are zillions of ways to do this! >> >>>You agreed that a few extra bits (say two bytes at least) are needed, so why >>>don't you like to simply compute them with Zobrist algorithm or something >>>similar? >> >>As this 4 connect problem is TOO simple. Why hash something if you can solve >>the entire game very quick by other means? >> >>The advantage of hashing is especially that something which can't be stored >>within a few bytes can be stored now in only a few bytes, running the >>risk that you of course get a hashcollission which messes up search, >>i'm pretty sure that instead of using 32 bits hashing it's smarter >>to store the entire position as that gives 100% garantuee on not >>giving a collission, >> >>even with 64 bits of Zobrist hashing you don't have a safe theoretic >>feeling, perhaps you are using a wrong random generator or just have >>bad luck, whereas you now can simply solve the entire game in a theoretic >>very correct way! >> >>No hash algorithm beats a true storage of the entire >>position if it's possible in just the same number of bits! >> >>Zobrist gives especially a lot of safety there where you don't see all >>the legal positions. >> >>In chess it's *very* unlikely that both all pawns are getting moves to the >>6th row and all pieces messed up over the board (just for the pawns >>on 6th row you already need a fullwidth search depth of 48 ply from >>openings position). >> >>So Zobrist is strong if nearly all positions look like each other >>with only relative small changes. >> >>Here we talk about a game where we see potentially *all* positions, >>so the chance you get a collission is relatively seen bigger! >> >>>Bye, >>>Carmelo > > I'm sorry to get into your argument, but I think you're missing that, what he >means is "what to use as an index for the table where you store the positions. >If I'm not wrong, he wants to _store_ the whole position but use zobrist to >calculate _indexes_ to those stored positions. And that makes perfect sense to >me, because if you use the n-less significant bits of the signature (as we do in >chess) you're gonna get the same index for a buch of very similar positions. Yes a very quick way to store is 32 bits zobrist hashing and a true store of the position! Another and quicker way is to XOR the 63 bits of the true storage internal with each other, though i'm sure that zobrist gives a better division over the hashtable as that... But one can invent another zillion ways of indexing them :) > José C.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.