And I gave a possible idea what to test. Still awaiting yours (logging is always good, but not a concrete test).Sven Schüle wrote:The OP asked for help to find the cause of his problem.
It is easy to test. If the issue is not there without hash tables, then it has something to do with them, probably some bug lurking.So it is not about "speculation".
Depends on the engine, I guess. My measurements, as I said, show the opposite. And not only in extreme positions like this, but also in normal opening positions.You can be 99.99% sure that trying the null move at the root node leads to nowhere.
"Can't" assumes a mature code base where things work as expected. In that phase of the project "it can't" would probably be my last line of thought.And I also explained why a score resulting from a null move failing *low* can't make it into the hash table.
+mate from the perspective of black during null move, so it is stored as +mate. But when retrieving during the actual search, it is retrieved from the perspective of white, only that it is still +mate because the binary value didn't change.And again, the OP wrote "+mate in 1", not "-mate in 1".
The value of testing here is that it might show an underlying problem that would also arise lateron without null move at root - because the right to move might not yet be encoded into the hash table handling.
Because even if null move at root level were useless, it clearly shouldn't make the engine lose a winning position. Dropping the null move may solve the issue in this position, but I think it would be covering the underlying problem instead of solving it.