pawn hash table difference

[ethanara]

What is the real coding difference Between pawn hash table and normal transposition tables?
I mean, how do you strip the position so there is only pawns, evaluate, them, and then save them ?
Edit: What is the expected gain from pawn hash tables when you already have tt???

[Edmund]

It very much depends on the complexity of your pawn evaluation. The more complex your pawn evaluation the higher the gain with a pawn tt. The advantage of it being that pawn structure doesn't change so much and thus not many entries are needed and you will still get hit-rates of > 99%.

Usually a separate hash key is kept that gets only updated on pawn moves. A variation to this also hashes the king position and thus adds pawn shelter evaluation into the pawn tt value.

[Sven]

Usually a separate hash key is kept that gets only updated on pawn moves.

And moves capturing pawns.
Sven

[bob]

What is the real coding difference Between pawn hash table and normal transposition tables?
I mean, how do you strip the position so there is only pawns, evaluate, them, and then save them ?
Edit: What is the expected gain from pawn hash tables when you already have tt???

Expected gain: Your pawn scoring is free. You will see 99%+ pawn hash hits, which means whatever code you stick in there is free and doesn't cost you any additional time.

Pawn hash has no piece information except for the king position. Therefore, pawn scoring can not include any piece information except for the king, or you will have some interesting bugs to deal with (been there, done that, got the T-shirt.) I have a separate passed pawn evaluation that is outside the hashing, because it needs to include pieces for blockading, preventing passed pawns from running, etc... so it is outside the code where the hash is checked or stored.

[rbarreira]

The tt is a cache of search results, the pawn hash table is a cache of pawn eval results. So the pawn hash table is simpler in the sense that it doesn't need to deal with stuff like node types, depths etc.

[Volker Annuss]

A hash code for the pawn positions and a score are mandatory for a pawn hash table. But you can put much more information into it that is expensive to calculate and that is useful in other parts of the evaluation. For exapmle passers, backward pawns and open files.

[ethanara]

Cant you also make a hash table for rooks? There can only be about 15 million different positions with four rooks, and you could add info such as rook on 7th .
Has anyone tried that?

[lucasart]

What is the real coding difference Between pawn hash table and normal transposition tables?
I mean, how do you strip the position so there is only pawns, evaluate, them, and then save them ?
Edit: What is the expected gain from pawn hash tables when you already have tt???

a pawn hash table is just a normal hash table, except that:
it stores a zobrist key for pawns only (you can remove castling rights, turn of play, and pieces). therefore you'll have a lot of hash table "hits" because in the search the pawn structure takes mucyh less "possible forms" than the whole chess board

[hgm]

The Rook-on-7th info does not depend on the pair of Rooks.You can simply put it in the piece-square tables. But for most advanced engines the bonus depends on the presence of Pawns on that same Rank, or of a King on the 8th. You could not see that from Rook positons only. In fact, the position of one Rook has very little effect on what is a good square for the other. Connecting the Rooks could get a bonus, but it is quite cheap to test 'on the fly', and thus not worth tabulating (plus that it also does not depend on Rook locations only, but on intervening pieces of any type as well).

For Pawns this is all completely different. How good a Pawn is on a certain square depends almost exclusively on where other Pawns are. A white Pawn on c4 could be a winning advantage (e.g. protected passer) or a lethal weakness (e.g. isolated doubled pawn).

[rbarreira]

Cant you also make a hash table for rooks? There can only be about 15 million different positions with four rooks, and you could add info such as rook on 7th .
Has anyone tried that?

The rook eval is probably too lightweight to get accelerated by a hash table. Accessing a big hash table almost always means loading a value from memory, which takes much longer than a few ALU operations.

If you have a complex enough rook eval, it could be worth it I guess.