Transposition table random numbers

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Transposition table random numbers

Post by bob »

AlvaroBegue wrote:
bob wrote:While I agree it is possible to have ambiguities, how often would you find the _exact_ same position, but with ep captures possible on different squares?
1. e4, d5 2. e5, f5

1. e4, f5 2. e5, d5

That wasn't so hard to imagine...
Now move down into the game beyond where the opening book runs out and see how easy that is. :)
AlvaroBegue
Posts: 931
Joined: Tue Mar 09, 2010 3:46 pm
Location: New York
Full name: Álvaro Begué (RuyDos)

Re: Transposition table random numbers

Post by AlvaroBegue »

Any situation where there is a pawn on the 5th rank flanked by two opponent's pawns is ambiguous. Given how easy to fix this is, why risk it?

I don't think anyone can seriously argue that en-passant info shouldn't be hashed properly. Having a separate entry in a table for each possible pawn costs you 7 extra 64-bit numbers. You can afford it.
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Transposition table random numbers

Post by bob »

AlvaroBegue wrote:Any situation where there is a pawn on the 5th rank flanked by two opponent's pawns is ambiguous. Given how easy to fix this is, why risk it?

I don't think anyone can seriously argue that en-passant info shouldn't be hashed properly. Having a separate entry in a table for each possible pawn costs you 7 extra 64-bit numbers. You can afford it.
I am not proposing that you ignore it. I was simply proposing how one could use a very minimal set of PRNs. I've always hashed by ep target file in Cray Blitz and Crafty...
wgarvin
Posts: 838
Joined: Thu Jul 05, 2007 5:03 pm
Location: British Columbia, Canada

Re: Transposition table random numbers

Post by wgarvin »

AlvaroBegue wrote:Any situation where there is a pawn on the 5th rank flanked by two opponent's pawns is ambiguous. Given how easy to fix this is, why risk it?

I don't think anyone can seriously argue that en-passant info shouldn't be hashed properly. Having a separate entry in a table for each possible pawn costs you 7 extra 64-bit numbers. You can afford it.
For normal chess, the first and last rank of pawn keys of each color is not normally used, so unless you took some special pains to squeeze them out of your zobrist table, you already have 16 keys of each color that you could use to represent features such as enpassant file.
wgarvin
Posts: 838
Joined: Thu Jul 05, 2007 5:03 pm
Location: British Columbia, Canada

Re: Transposition table random numbers

Post by wgarvin »

We've discussed before about hashing of enpassant squares, in this thread and probably others.
User avatar
hgm
Posts: 27790
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: Transposition table random numbers

Post by hgm »

bob wrote:I am not proposing that you ignore it. I was simply proposing how one could use a very minimal set of PRNs. I've always hashed by ep target file in Cray Blitz and Crafty...
If you drop the requirement of absolute correctness, you can save a lot more. It also will not happen too often that a King will be on a1 or h8 in otherwise exactly the same position. So you might as well use the same key for Ka1 and Kh8...