how can IID with null allowed cause wrong mate move from tt

[Ras]

The OP asked for help to find the cause of his problem.

And I gave a possible idea what to test. Still awaiting yours (logging is always good, but not a concrete test).

So it is not about "speculation".

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.

You can be 99.99% sure that trying the null move at the root node leads to nowhere.

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.

And I also explained why a score resulting from a null move failing *low* can't make it into the hash table.

"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 again, the OP wrote "+mate in 1", not "-mate in 1".

+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.

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.

[Ras]

There's really no reason why hash table can't be used during null move search

My idea was that these null move positions are not "real", thereby clogging the hash tables. Depends also on how deep the null search tree actually grows. If it is quite shallow, than the chance for transpositions is minor anway.

At a depth of 3, I've tried transposition tables in the pre-ID move sorting, and when storing/retrieving at depth == 0 (right at QS start), I got less than 10% transposition hits.

as long as side to move is part of the hash

That's of course also possible, yes.

[Karlo Bala]

You can be 99.99% sure that trying the null move at the root node leads to nowhere.

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.

And, what are you doing with the null-move result at the root?

[Evert]

+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.

But the hash signatures should not match, because you still flip the side to move (and should update the hash key) when doing a null-move.

[Evert]

And, what are you doing with the null-move result at the root?

The only real benefit from it that I can think of is quickly identifying inappropriate aspiration bounds.
You can use threat detection as well, but I don't think that would scale well (you only really care about the best move, normally, which you take from the previous iteration).

[Ras]

And, what are you doing with the null-move result at the root?

The score doesn't matter, it is only the move itself I'm interested in. When doing the actual move searching, this move will be the preferred answer move at the next depth level.

I don't see anything astonishing here, that's part of how I play chess myself. I'm checking whether the opponent has a good move and how I can use my right to move for dealing with that move before the opponent can play it.

[Ras]

But the hash signatures should not match, because you still flip the side to move (and should update the hash key) when doing a null-move.

Correct, and usually, I would not come up with such an idea. However, the engine in question is in a very early phase of development where bugs left and right are normal.

Just assuming that this and that and that can't be basically means assuming that the code works correctly. Given Bd2??, this assumption clearly doesn't hold water.

So my line of thought is: where might such a bug be hiding that could explain the observed behaviour? What parts would I examine more closely?

The answer is a compromise of how large the chances for success are in relation to how difficult it is to test. I would first go for what has easy test scenarios, minimizing the debug effort.

[Ras]

Of course, the score could also be used - if the score massively differs from the calculation of the turn before, then this is a hint to a serious threat that has to be dealt with immediately. Like for instance getting mated as in the original position of the thread.

[Evert]

Well, yeah, there are bugs. And forgetting to factor in the side to move in the hash key could well be one of them.
It's a little disingenious to say that this is what you suggested though, since what you said was "positions that arise from a null-move don't. Belong in the main transposition table", which is wrong.

[Evert]

The score doesn't matter, it is only the move itself I'm interested in. When doing the actual move searching, this move will be the preferred answer move at the next depth level.

How big is this effect? I would expect killers and hash moves to dominate very quickly.