Now move down into the game beyond where the opening book runs out and see how easy that is.AlvaroBegue wrote:1. e4, d5 2. e5, f5bob 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, f5 2. e5, d5
That wasn't so hard to imagine...
Transposition table random numbers
Moderators: hgm, Rebel, chrisw
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: Transposition table random numbers
-
- Posts: 931
- Joined: Tue Mar 09, 2010 3:46 pm
- Location: New York
- Full name: Álvaro Begué (RuyDos)
Re: Transposition table random numbers
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 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.
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: Transposition table random numbers
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...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.
-
- Posts: 838
- Joined: Thu Jul 05, 2007 5:03 pm
- Location: British Columbia, Canada
Re: Transposition table random numbers
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.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.
-
- Posts: 838
- Joined: Thu Jul 05, 2007 5:03 pm
- Location: British Columbia, Canada
Re: Transposition table random numbers
We've discussed before about hashing of enpassant squares, in this thread and probably others.
-
- Posts: 27790
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Transposition table random numbers
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...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...