Hash table bug

[zenpawn]

[d]2rr3k/2q2pb1/p3bN1p/3p4/4p2Q/1B6/PP2RPPP/K2R4 w - - 0 35

In this already losing position, my engine, playing white against Isa in a 5-minute game, thought for 2 seconds, reaching a depth of 5, and played the howler 35.Rf1??

Thankfully, it's reproducible at a fixed depth of 5. It only occurs with the transposition table enabled.

With TT:
1 -922 9 2822 h4h6 g7h6
1 113 10 10296 e2e1
1 168 11 17945 e2c2
2 139 12 34734 e2c2 c7e5
3 102 24 108079 e2c2 c7e5 c2c8
4 102 29 199363 e2c2 c7e5 c2c8 d8c8
5 70 261 3778419 h4h6 g7h6 f2f3 e4f3
5 156 272 3946856 d1b1 c7c1
5 158 272 3946861 d1g1 g7f6
move d1g1

Without TT:
1 -922 13 2822 h4h6 g7h6
1 113 14 10296 e2e1
1 168 15 17945 e2c2
2 139 16 34777 e2c2 c7e5
3 102 23 120947 e2c2 c7e5 c2c8
4 102 32 228537 e2c2 c7e5 c2c8 d8c8
5 -239 774 12013474 e2c2 c7e7 c2c8 d8c8 b3d5
move e2c2

I've created some rather large logs to compare both cases, but nothing is jumping out at me. Any tips on debugging TT issues? Maybe some standard asserts I could add? (Note: I'm using fail hard.)

[Sven]

Some standard asserts:
1) Incrementally updated hash key is identical to hash key calculated from scratch
2) Hash key before making a move X is identical to hash key after unmaking move X (i.e., after returning from subtree)
3) Bounds checking of hash table index (lower N bits of hash key)

#2 is often solved automatically by pushing the hash key on a stack - provided you restore it correctly.

Since you already have logs you might also try to check at which point in iteration 5 the engine starts to change its mind and wants to play 1.Qxh6 (before switching to Rb1 and then Rg1).

You might also want to check whether there is a problem with the transformation of mate scores from/to TT.

[MahmoudUthman]

what is the definition of your mate score ?

[zenpawn]

Some standard asserts:
1) Incrementally updated hash key is identical to hash key calculated from scratch
2) Hash key before making a move X is identical to hash key after unmaking move X (i.e., after returning from subtree)

These two checked out OK. I used to have these tests back when I added Zobrist keys initially, but removed them sometime after. Put them back just now and all is good.

3) Bounds checking of hash table index (lower N bits of hash key)

Could you elaborate?

#2 is often solved automatically by pushing the hash key on a stack - provided you restore it correctly.

Mine's done incrementally in make/undo, so this is always a good assert.

Since you already have logs you might also try to check at which point in iteration 5 the engine starts to change its mind and wants to play 1.Qxh6 (before switching to Rb1 and then Rg1).

I'll have to keep staring at this. It definitely starts out with Rc2 as the TT move. It doesn't best alpha, so it widens that side of the aspiration window. Rc2 still doesn't improve enough, but this time other moves do. Sounds like I should focus on why Qxh6+ is seen as viable. In particular, which TT entry is giving it a good score.

You might also want to check whether there is a problem with the transformation of mate scores from/to TT.

I do adjust based on ply, but I'm not convinced it's completely correct yet as I found it plays endgame mates better without mate-distance pruning enabled. Still, I don't think that would cause this since the mate score plus or minus some ply is still going to be greater than any material deficit.

[zenpawn]

what is the definition of your mate score ?

99999

[jwes]

The first thing I would look at is why your program thinks Qc1 is not a good reply. Either use a debugger or put in enough log statements to see why.
Three other things:
1. the PV from ply 4 does not show a score at ply 5.
2. The first line at ply 5 (5 70 261 3778419 h4h6 g7h6 f2f3 e4f3) has a very odd score.
3. The node count for ply 5 seems very high.

[zenpawn]

The first thing I would look at is why your program thinks Qc1 is not a good reply. Either use a debugger or put in enough log statements to see why.
Three other things:
1. the PV from ply 4 does not show a score at ply 5.
2. The first line at ply 5 (5 70 261 3778419 h4h6 g7h6 f2f3 e4f3) has a very odd score.
3. The node count for ply 5 seems very high.

Definitely been hanging out in the debugger and log files.

I agree with #2. That it lets Qxh6+ get anywhere is crazy.

What do you mean by #1?

I think #3 is because it had to widen the aspiration window.

[MahmoudUthman]

what is the definition of your mate score ?

99999

I meant inside the search or do you use a 32 bit to store it the TT, any way ensure that the distance between the +-mate in 0 scores and the +-maximum of your score type >=MaxPly

[zenpawn]

what is the definition of your mate score ?

99999

I meant inside the search or do you use a 32 bit to store it the TT, any way ensure that the distance between the +-mate in 0 scores and the +-maximum of your score type >=MaxPly

That's the value in the search too, minus the ply.

[jwes]

The first thing I would look at is why your program thinks Qc1 is not a good reply. Either use a debugger or put in enough log statements to see why.
Three other things:
1. the PV from ply 4 does not show a score at ply 5.
2. The first line at ply 5 (5 70 261 3778419 h4h6 g7h6 f2f3 e4f3) has a very odd score.
3. The node count for ply 5 seems very high.

Definitely been hanging out in the debugger and log files.

I agree with #2. That it lets Qxh6+ get anywhere is crazy.

What do you mean by #1?

Normally an iteration starts off with the PV from the last iteration, searches one ply deeper, and shows the score before searching the next move.

I think #3 is because it had to widen the aspiration window.

Do you have killer moves? Qc1 refutes most moves.