Author: José Carlos
Date: 09:54:53 02/01/01
Go up one level in this thread
[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. 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.