Natural TB

[syzygy]

It will make the engine score a TB win as a mate, once beta gets there...

That was what I meant. I suppose that by "once beta gets there" you mean in the process of enlarging the root aspiration window. As you keep failing high for any smaller beta.

Yes, I did not mean to contradict you.

If you score conversion to a TB win as mate, it would score better than any real mate, as the real mate takes time, and will get a mate-in-N score. So in KQBNK it will shy away from a mate without conversion, and sac a piece to convert to a won successor.

Looking at the code, it seems this so-called "natural" SF does not probe at all once beta exceeds VALUE_KNOWN_WIN. This of course ensures search instability, which, I guess, is only natural.

And Marco indeed seems to think that knowing WDL of root moves is enough to filter out suboptimal moves. I have to wonder, why did I ever bother generating those DTZ files if they are not needed at all to win all won endings.

This once again shows that applying clear thought and logic to a problem or task more often than not pays off and avoids a lot of unnecessary monkeying around.

[syzygy]

I was able to achieve desired results in SF Matefinder with this approach:

https://github.com/jhellis3/Stockfish/c ... 16f7ade6d7


A good test position:

8/2P1P3/3k4/8/8/4K3/P2p1p2/8 b - -

So, somewhat simplified: if the position being searched is overwhelmingly won or lost anyway, then don't accept a TB cutoff. I guess that makes sense.

In principle, TB cutoffs should always be good if beta is not yet in mate territory. But once beta gets there, suddenly ignoring TB cutoffs will usually (i.e. unless the win is really trivial) only make the search lose track of the win. (Your approach obviously does not suffer from this instablity.)

Ideally, once the engine has determined that it can have at least a TB win, it should start searching beyond the TB probe without doing further TB probes, but in such a way that if that search beyond the TB probe does not return a MATE, the search at the TB position still returns the TB win value.

With lazy SMP, i.e. without splits, this could probably be implemented relatively easily by having a per-thread "use the TBs" flag. Once you enter the TBs and the flag is enabled, do a probe. If you want to search on (because the position is winning and beta is very large), disable the "use the TBs" flag and invoke search() recursively. Switch the "use the TBs" flag back on. When the value returned by search() is not winning, return a TB win. If the value returned by search() is winning, return that score.

[mcostalba]

Ideally, once the engine has determined that it can have at least a TB win, it should start searching beyond the TB probe without doing further TB probes, but in such a way that if that search beyond the TB probe does not return a MATE, the search at the TB position still returns the TB win value.

With lazy SMP, i.e. without splits, this could probably be implemented relatively easily by having a per-thread "use the TBs" flag. Once you enter the TBs and the flag is enabled, do a probe. If you want to search on (because the position is winning and beta is very large), disable the "use the TBs" flag and invoke search() recursively. Switch the "use the TBs" flag back on. When the value returned by search() is not winning, return a TB win. If the value returned by search() is winning, return that score.

Isn't easier to just probe tb at the end of the search, before returning a fail low and eventually correct it?

And symmetrically check before returning a fail high and eventually correct it.

[syzygy]

Isn't easier to just probe tb at the end of the search, before returning a fail low and eventually correct it?

I wonder why you don't just reimplement TBs from scratch.

And I wonder how long it takes before you accept that people have spent time thinking about this. And those people are not stupid. If you think there is much simpler way that is equally good or better, then VERY LIKELY you are missing something. It is extremely unlikely that a trivial idea will not have been thought about by the many non-stupid people that have spent time thinking about this.

TBs should be probed and the search tree should be cut once the position gets there, because that achieves the main benefit: reduction of the size of the tree.

In addition, the WDLs should only be probed immediately after a capture (or pawn move), unless the WDL result is combined with DTZ. Normally, it is never necessary to probe WDL in other positions than immediately after a capture. Because the only way to get to a 6-piece position is by a capture from a 7-piece position. (It is different at the root: therefore DTZ should be used there too.)

[mcostalba]

I was able to achieve desired results in SF Matefinder with this approach:

https://github.com/jhellis3/Stockfish/c ... 16f7ade6d7


A good test position:

8/2P1P3/3k4/8/8/4K3/P2p1p2/8 b - -

Code: Select all

info depth 39 seldepth 48 multipv 1 score mate 17 nodes 184662043 nps 2506543 hashfull 999 tbhits 1243053 time 73672 pv d2d1q e7e8n d6d7 c7c8q d7c8 e3f2 d1d8 e8g7 d8f8 f2e3 f8g7 a2a4 g7a7 e3d2 a7a4 d2e2 a4e4 e2f2 c8c7 f2g3 e4e2 g3f4 c7d6 f4g5 d6e6 g5f4 e6f6 f4g3 f6f5 g3h3 f5f4 h3h4 e2h2

This is the latest version of "Natural TB", with TB probing moved at the end of the search(*)


(*) I know that Ronald, the syzygy author, thinks this is a "trivial idea", but apart from some general arguments about the smartness of people involved in TB before me, I didn't get any specific refutation, so I have tried it...I love trivial ideas

[syzygy]

Marco, if you really insist on screwing up SF's TB implementation, then by all means do so.

However, it is much easier and will save you many many more lines of codes (drool) if you just rip it out altogether. And be honest, that is what you would like most.

[mcostalba]

Marco, if you really insist on screwing up SF's TB implementation, then by all means do so.

However, it is much easier and will save you many many more lines of codes (drool) if you just rip it out altogether. And be honest, that is what you would like most.

I think you take it too personal.

I can somewhat understand you: TB is your brainchild, it took you a lot of time (since 2000) and efforts to come up with syzygy and I have huge respect for this and for your persistence on this difficult topic.

I really don't want to screw up anything!

If for a moment you can let your angriness toward me (totally undeserved BTW) don't obfuscate your mind you could see it VERY clearly.

I am perhaps the only one that took the effort to read your source code line by line (and I really mean it!), I would have not done so if I don't think there is some valuable content in it.

OTH we can't just remain standing still looking at the beautiful picture! I am a coder, I want to code, to experiment, to change things: this is not for disrespect but for curiosity.

BTW I made up my mind one of the reasons to probe at rule50 == 0 is for performance, OTH this is the root cause of the 'sacrifice to simplify' artifact that sounds so unnatural. So I have used a different approach: probe everywhere but cache the result. Amazingly a small cache is able to hit in 60% of cases even on a bench of very different positions (in normal game where searched positions are more "similar" I expect hit rate to be even higher). Anyhow the speed up is huge and very sensible already.

[lucasart]

Marco,

Regarding fail high/low instead of prune , Ronald actually made a couple points:
* as you keep failing high, or low, and eventually you exit the value_known_win, it is possible sf will lose track of the win.
* you introduce search instability also, because the return value now depends on the bound condition.

But, of course, whether these problems have any *practical* incidence remains to be proven. And you're perfectly right not to accept general arguments about the smartness of people as a proof, because they dont prove anything.

[Michel]

I think Ronald also made the following point. In non-PV nodes it makes no sense to postpone WDL probes (even disregarding the 50 move rule issue). You will get exactly the same result if you probe now, or if you search x more moves and then probe (if your TB's aren't buggy ).

In the second option you have simply searched a bigger tree for no benefit at all.

The only case where some cosmetic tweaks may be possible is when you are already looking for a mate (since a hard mate in the tree is better than a TB win). But this is a very rare event (in adjudicated games it probably never happens).

[mcostalba]

I think Ronald also made the following point. In non-PV nodes it makes no sense to postpone WDL probes (even disregarding the 50 move rule issue). You will get exactly the same result if you probe now, or if you search x more moves and then probe (if your TB's aren't buggy ).

I don't think so.

Using only WDL, you need to preserve the draws (eventually 50 moves draw) detected by the engine and so you need first the engine to search then, just under a small set of cases, eventually overrule the search: the draws are preserved.

Lucas, returning a value that depends on the bound condition is called hard-fail. This is of course a well proved and sound scheme in alpha/beta. Maybe the current code introduces some instabilities but it is very difficult to state it just looking at it. Even the whole concept of search instability is filled with myths and legends and anecdotes and in many cases has been grossly misused to dismiss valuable and powerful techniques like LMR or null search. So I would be very cautious before to take "search instability" as a proved fact.