I don't see. But given your explanation, I have 50%.
If you do "nNumberOfPieces & 0x07" you get the lower 3 bits.
This means that you have 8 populations, with the number of pieces indicated:
- 32, 24, 16, 8, (0) pieces
- 31, 23, 15, 7
- 30, 22, 14, 6 (tb)
- 29, 21, 13, 5 (tb)
- 28, 20, 12, 4 (tb)
- 27, 19, 11, 3 (tb)
- 26, 18, 10, (2)
- 25, 17, 9, (1)
If we have 4 captures on average in a search tree, only 50 % of the populations are used.
In order to have optimal use of the hash key, you need to have exactly 8 captures in a search tree, which is not the case. First weakness spotted.
Given that we are not interested in 2 pieces, 1 and 0 are impossible, and when using up to 5/6 man endgame tablebases, we have 33% more positions in the first 2 (or first 6 with tablebases), and the last 2 are less used. Indeed, this is sub-optimal. Second weakness spotted !
In order to use each entry more than 1 time, you will need to have more than 8 captures in a search tree. This is unlikely and a higher number of hash collisions caused by this is highly theoretical.
In order to get optimal spread in my proposal, you would need to use 2 bits and combine 4 man tablebases, or 3 bits and 8-man tablebases.Dependency spotted
If your search tree is on average 4 captures, it is indeed better to use only 2 bits instead of 3 bits to achieve almost optimal distribution. Downside: Using only 2 bits and not 3 or 4 makes cleaning the hashtable extremely complex and no longer an improvement on the standard zobrist hashtable.
Using only 1 bit for even or odd number of pieces would be a valid alternative. We still can use it for tracking 3-fold repetition and it would not have an impact on distribution and hence collision. Combine this with an even-number tablebase in order not to disturb the distribution.
In summary, I believe the idea of having 3 bits with the number has been refuted, and unless there is a gain in clearing the hashtable, it should not be done.
However, using 2 bits and 4 or 8 man tablebases or 1 bit and using no or even-man tablebases is still on the table.
I don't see any obstacle on using stm bit neither. I believe this latter is an improvement on zobrist. Lets call it Zobrist+stm.