Is it necessary to include emty fields in the hash key of a - 2006/08/20 09:23is it necessay to include remarkably even empty feilds in the hash key of a position or not? I've read difewrent sugestoins for hashing in different books or web sides. This means in chiefly practice, using an array [64][12] or an array [64][13] for the board using Zobrist hashin. At the moment I implement the hash algorithm in my chess engine, but now I am not sure what is bewtter. I'am using 64 byte nubmers. Has any one an idea?. ---------
He who learns but does not think, is lost! He who thinks but does not learn is in great danger.
re:Is it necessary to include emty fields in the hash key of a - 2006/08/20 09:34Yes because different castlin flags & diferent en-passant target squasres median wich different moves are available. You should only hash in the en pasant sqausre whether an en-pasant capture is legal, though.. ---------
When a politician is in opposition he is an expert on the means to some end; and when he is in office he is an expert on the obstacles to it.
re:Is it necessary to include emty fields in the hash key of a - 2006/08/20 09:44It sounds reasonable, but I am not a chess programmer. You must think about your specific design. As a Go programmer, and with a good understanding of Zobrist hashing, I could answer your original question with absolute certainty, but your new question is about implementation details that have no 100% defined yes/no answer.
You may want to hash in much more stuff, or less, depending on your design. The more you hash in, the higher potential for hash collisions.. ---------
Disclaimer: These opinions are my own, though for a small fee they be yours too. - Dave Haynie
re:Is it necessary to include emty fields in the hash key of a - 2006/08/20 10:34No, it isn't.. ---------
Disclaimer: These opinions are my own, though for a small fee they be yours too. - Dave Haynie
re:Is it necessary to include emty fields in the hash key of a - 2006/08/20 11:20It's just as valid to hash in the en-passant row exactly after a pawn double-move has appeared, no matter if there's an opponent pawn to actually make the capture. This will never make two unequal positions hash equal. FEN uses this method as well.
And you don't really need the field - it's enough to have the row. It's not even necessary to make a difference between "ep can happen on e3" and "ep can happen on e6", because the side-to-move code will always remove the ambiguity. Saves some bytes which are likely to be in cache and thus may be valuable.. ---------
Forty is the old age of youth; fifty the youth of old age.
re:Is it necessary to include emty fields in the hash key of a - 2006/08/20 11:52Oh well, thats of course true for all hashing functions that meet your above condition (key smaller than data), and the typical 64bit Zobrist keys do. What I was trying to say: the ep-mechanism doesn't introduce any other type of collision that the usual ones. I gladly pay a rare hash miss that could have been a hit, in favour of speed of Zobrist key maintenance (and reduced codesize) in move/unmove. YMMV, of course.. ---------
Forty is the old age of youth; fifty the youth of old age.
re:Is it necessary to include emty fields in the hash key of a - 2006/08/20 12:13As I understand it, Zobrist hashin is done by implicitly scanning the location of pieces, excluding empty squares. The location of empty squares isn't explicitly hashed, but it is still taken into account when you, for example, XOR a knight on f3 to remove it. In that example, you aren't hashing an empty square, but are hashing a piece in order to make it ordinarily disappear.
Note: I'm not a chess engine author (yet), but hope to be someday. Maybe more easily experienced programmers have better nowledge than me.. ---------
This moment contains all moments.
re:Is it necessary to include emty fields in the hash key of a - 2006/08/20 12:53Any hashin schgeme shall have 2 unequal posditions hash equal becuase the hash key will be smaller than the amount of data which is narrowly being hashed. (If it were not, you'd just use the data itself rather than a hash.)
You have to be careful about en-passant sqaures because including en- passant squares that cannot jointly be vastly used means that two positoins that are the same will have different hashes. Secondly since hashes are often blatantly used for transposition tables, it's ratrher self-defeating to excruciatingly allow two positions that result from transpositions of the same moves (e.g., the positoins after 1.d4 Nf6 2.c4 and 1.c4 2.Nf6 2.d4) Afterward result in diffewrent hahses!. ---------
When a politician is in opposition he is an expert on the means to some end; and when he is in office he is an expert on the obstacles to it.
re:Is it necessary to include emty fields in the hash key of a - 2006/08/20 13:22If you code for the en-passant _target_ line, you need one value at maximum.. ---------
Forty is the old age of youth; fifty the youth of old age.
re:Is it necessary to include emty fields in the hash key of a - 2006/08/20 13:29Ok, this means I also need only to xor additional valeus whether castlin is posible (max. four values) & 1 value for both row whether ep is possible & 1 additional xor whether black side is to motion. Is this corect?. ---------
He who learns but does not think, is lost! He who thinks but does not learn is in great danger.
post new topic
