Can it be a "real" hash collision

[Ronald]

I had a quick look at your sourcecode, and indeed you don't store the score for the move when the stopflag is set, however you still update the pv if the score is higher then alfa (and also update some history info etc.) (in negamax and searchroot). I'm not sure if that pv will propagate through your search but that might be the problem. I think you could just return a value if the score is based on a stopped search and thus skip the rest of the code (after //update best score etc.).

This might also help you if you want to use the pv of a partially completed iteration. As long as you make sure that the pv is only updated for a completed search and not for a stopped search, you can return that pv as the best move.

[xr_a_y]

I had a quick look at your source code, and indeed you don't store the score for the move when the stopflag is set, however you still update the pv if the score is higher then alfa (and also update some history info etc.) (in negamax and searchroot). I'm not sure if that pv will propagate through your search but that might be the problem. I think you could just return a value if the score is based on a stopped search and thus skip the rest of the code (after //update best score etc.).

This might also help you if you want to use the pv of a partially completed iteration. As long as you make sure that the pv is only updated for a completed search and not for a stopped search, you can return that pv as the best move.

Thanks, this might be really helpful. You're right, I probably should not update killer/history/counter if stopflag is set.
For the PV it is probably wrong also but will not affect anything, this is not really use (I use the TT to get the PV instead).

In the current Xiphos master for example there is indeed a

Code: Select all

if (search_status.done)
      return 0;

Just before looking if the score is > alpha.

Thanks again !