value = -(100000 + (MATE - value)/2);
which is not the same as what you have.
Second point, you should only change a local copy of "value" at this point which is then only used for printing, while the original "value" should keep its mate scoring system that your search needs (MATE - ply resp. -(MATE - ply)).
Volker Annuss wrote:Your nullmove does not change hash key. It must be different because the side to move has changed.
Hash probe code regenerates the key before probing. It's not much of an overhead to scan the board to generate a key from scratch.
But what if you need the updated hash key already before probing? Actually I see where that is the case: in IsTrivialDraw() you need the hash key for repetition check, and you call it prior to hash probing ... That might lead to a couple of wrong decisions regarding a repetition draw, which could of course lead to weaker play. Not sure, though, whether the effect would be so drastical to see null move delivering almost zero improvement.
value = -(100000 + (MATE - value)/2);
which is not the same as what you have.
Second point, you should only change a local copy of "value" at this point which is then only used for printing, while the original "value" should keep its mate scoring system that your search needs (MATE - ply resp. -(MATE - ply)).
ZirconiumX wrote:Since the fifty-move counter is zeroed, this should never trigger a draw claim after nullmove.
But you store that wrong hash key in bd->rep[...] and use it later on for repetition checks some plies after the null move, and there it might fail.
Okay, I get your point now. I'll put this on the to-fix list, along with all the other mysterious crashes I can never reproduce (Ilari, if the program segfaults, cutechess terminating it is not helpful because i get no core dump to work with).
SPRT failed, which was not entirely unexpected. Still, it's progress from being a 200 Elo regression.
Score of New vs Old: 248 - 320 - 142 [0.449] 710
ELO difference: -35.35 +/- 22.95
SPRT: llr -2.97, lbound -2.94, ubound 2.94 - H0 was accepted
Finished match
How did you come up with depth >=4? Depth >= 2 works best for me. Make sure you call qsearch when depth <= 0 and not depth == 0 if you make this change.
How did you come up with depth >=4? Depth >= 2 works best for me. Make sure you call qsearch when depth <= 0 and not depth == 0 if you make this change.
Nullmove reduces by R + 1. My R is 3, so 3 + 1 = 4. I'll fiddle about with it after this latest test (requiring 4 or more pieces for the side to move) runs to completion.
How did you come up with depth >=4? Depth >= 2 works best for me. Make sure you call qsearch when depth <= 0 and not depth == 0 if you make this change.
Nullmove reduces by R + 1. My R is 3, so 3 + 1 = 4. I'll fiddle about with it after this latest test (requiring 4 or more pieces for the side to move) runs to completion.
Yes, but you can still do null move pruning, even if the remaining depth is less than 4.
How did you come up with depth >=4? Depth >= 2 works best for me. Make sure you call qsearch when depth <= 0 and not depth == 0 if you make this change.
Nullmove reduces by R + 1. My R is 3, so 3 + 1 = 4. I'll fiddle about with it after this latest test (requiring 4 or more pieces for the side to move) runs to completion.
Yes, but you can still do null move pruning, even if the remaining depth is less than 4.
You *can*, but the overhead of doing it at low depths starts to outweigh its benefits. Dorpsgek is an incredibly slow program at ~700knps. An extra 2 million nodes of overhead costs Stockfish little, but it costs Dorpsgek a lot more.