Natural TB

[Michel]

By scenario I mean primarily: what kind of root position are we searching, and what criteria determine whether some behaviour is better than other behaviour?

It goes without saying that everything we are discussing is for positions which have already been determined to be won/lost and where you are looking for a mate score.

The two scenarios where you should fail hard I think are as follows

(1) Zero window search in TBwon position

beta>TBWIN
fail low with bestValue<TBWIN

return alpha (motivation: you want an upperbound but TBWIN is a lowerbound).


(2) Zero window search in TBlost position

alpha<-TBWIN
fail high with bestValue>-TBWIN

return beta (motivation: you want a lowerbound but -TBWIN is a upperbound).

[Michel]

Everything follows from thinking of (non draw) TB scores not as hard scores but as bounds. Then one can simply follow the principles of a-b search.

The principles of a-b search don't deal with the choice between taking the TB cutoff (treating the TB node as a terminal node) and not (yet) taking it.

Yes they do. If beta>TBWIN then since TBWIN is a lowerbound it does not provide a cutoff. So you keep searching.

TB cutoffs are similar to hash cutoffs.

[jhellis3]

Why are you comparing alpha and beta with bestValue (== -VALUE_INFINITE)? Probably not what you intended.

Forgot it was reset, thanks.

[syzygy]

You could simply check (ss+1)->tbScore and if, for instance it is a TB loss then you can safely return a win, without continuing searching, so although you didn't TB probe at the beginning of the search(), it does not take a lot, in case of a winning position, to early cut-off the search, thanks to the TB score stored in the stack of the inner nodes.

Does this scheme seems reasonable?

You would have to be lucky to play the winning move first.

If you are in a winning position you don't have to be lucky, any move will do.

Think again.

Not in general case, but in many cases yes, for instance in KRvK any move will do.

And also in other cases, engine is usually good in finding the best moves early on already by itself.

I have completely lost your point.

Are you saying SF does not need TBs? Then just take the code out...

[syzygy]

By scenario I mean primarily: what kind of root position are we searching, and what criteria determine whether some behaviour is better than other behaviour?

It goes without saying that everything we are discussing is for positions which have already been determined to be won/lost and where you are looking for a mate score.

Not really. Marco is not making this distinction.

The two scenarios where you should fail hard I think are as follows

(1) Zero window search in TBwon position

beta>TBWIN
fail low with bestValue<TBWIN

return alpha (motivation: you want an upperbound but TBWIN is a lowerbound).

Depends on how you look at it.
Another point of view: TBWIN is the exact score of a TBwon position at depths insufficient to find mate.

With this point of view, you may return TBWIN.

Of course this exact score is not the exact score anymore in the next iteration (if the same position is searched with higher remaining depth), but that is normal in iterative alpha-beta.

Anyway, if we are talking about a TB won position, then it is difficult to talk about "seeing improvements" by switching to fail hard. Current SF either does not search TB won positions any further (in case the root position is not yet in the TBs) or searches such positions without probing TBs (in case the root position is in the TBs).

The only exception is TB root position and DTZ not available. In that case, current SF filters root moves with WDL and searches for a winning zeroing move (so probing and taking the TB cut after each move that resets the 50-move counter). This certainly does not give nice play and also its winning chances can be improved (in a position like a winning KBNvKN).

[Michel]

Another point of view: TBWIN is the exact score of a TBwon position at depths insufficient to find mate.

I do not like this. Exact scores are supposed to be some kind of unbiased statistical estimate for the expected score of a position (I know this is not rigorously defined but let's keep it as a guide line).

In the case of a TBWIN we know that the real evaluation is definitely > TBWIN. So TBWIN is not an unbiased estimate. So it is unnatural to treat is as an exact score.

A more practical reason why TBWIN should be viewed as a lowerbound is that it leads to the correct behaviour if beta>TBWIN (or alpha<-TBWIN) by simply using the a-b principle.

In contrast to Marco I believe one should not throw something that works well out of the window unless there is a really compelling reason for it.

[Rein Halbersma]

Ah, this seems so simple to implement. But the problem is that the normal search has many exit points and at all those points you would need to check against the TB score. That's a lot of ugly code.

You could make a small RAII class that takes the current score variable by reference, and does the check against the TB in its destructor. Then all exit points will be checked without ugly repetitive code.

[syzygy]

Another point of view: TBWIN is the exact score of a TBwon position at depths insufficient to find mate.

I do not like this. Exact scores are supposed to be some kind of unbiased statistical estimate for the expected score of a position (I know this is not rigorously defined but let's keep it as a guide line).

TB wins are pretty exact. Just like a "mate in 10" is an exact score even if one iteration later the position could turn out to be a "mate in 9".

A more practical reason why TBWIN should be viewed as a lowerbound is that it leads to the correct behaviour if beta>TBWIN (or alpha<-TBWIN) by simply using the a-b principle.

But since treating TBWIN as exact is just fine, it will also work fine in a-b.

However, for the current implementation it does not matter anyway. The question is what works best if the search modified to search "beyond" TB positions. I think the two approaches will perform very similarly, because (from my point of view) it is simply the difference between fail soft and fail hard.

[syzygy]

Ah, this seems so simple to implement. But the problem is that the normal search has many exit points and at all those points you would need to check against the TB score. That's a lot of ugly code.

You could make a small RAII class that takes the current score variable by reference, and does the check against the TB in its destructor. Then all exit points will be checked without ugly repetitive code.

I was thinking more of using a goto

[jpqy]

Did a little test ,played with 5men-syzygy
First one is with Marco last source
second is with Joseph last source

I see no difference in game play!

Core i7 2670QM 2cores, Blitz 5m 0

SugaR SE B7 4c - Stockfish 040616 64 POPCNTB 4 15.5 - 14.5 +1/=29/-0 51.67%
SugaR SE B7 4c - Stockfish 040616 64 POPCNTB2 15.5 - 14.5 +1/=29/-0 51.67%

JP.