Key collision handling

[tpetzke]

Actually I thought using 40 bits, because I had a hash structure with 2^20 slots. The address of the slot is determined by the 20 lower bits and in the slot itself I store 20 of the upper bits of the key for validation, so in total 40 bits of the key must match to produce an undetected collision.

I use a make move/unmake move scheme. If I perform an illegal move chances are very high that the board messes up completely. I performed illegal moves where I moved to a square where one of my pieces was located. This was overwritten by make move but not restored by unmake (as the move object did of course not contain it as captured piece).

Thomas...

[hgm]

Ah, that is the risk of storing redundant information: it creates the opportunity for inconsistent states,which later could cause undefined effects, including crashes. Itry to avoid that as much as possible.

So I don't store the captured piece with the move. I just take it from the to-square.

[Karlo Bala]

Also, it can be a good idea to have a heavily optimized, legal moves only move generator, even if this costs more time for execute/retract operations. The idea is to generate all of the moves at each full width node and then scan these for matches for the PV moves, transposition moves, killers, etc. This simplifies the move ordering code and also ensures that a false positive match will never crash the program because the program can never select an illegal move from the list. Note that at all of the ALL-flavor nodes, all of the moves have to be generated anyway while at the CUT-flavor nodes, a good move ordering is needed (so all the moves should be present). This also gives faster checkmate and stalemate detection.

Just a small addition:
If you are worried about performance, you can skip legal move generation in last ply since there are very few hash hits.

[tpetzke]

It is not redundant. The piece that is captured is not stored anywhere else and I have to store it at least once otherwise I'm not able to unmake the move correctly.

Thomas...

[tpetzke]

If you don't have a hash hit then you don't have a hash move that could be illegal.

[hgm]

It is not redundant. The piece that is captured is not stored anywhere else and I have to store it at least once otherwise I'm not able to unmake the move correctly.

Well, it is implicitly stored on the board. Without redundancy you would have to copy the contents of the to-square to the move structure (if that is where you want to store it for UnMake) the moment you make the move.

[Karlo Bala]

If you don't have a hash hit then you don't have a hash move that could be illegal.

Yes, but point was that he can use an incremental move generator in leafs to get some speedup without even probing for a hash move, because in leafs there is no hash move most of the time.