Has SF 24.9. actually regression in mate finding?

[Jouni]

The patch "allowing singular extension in mate positions" was tested with 200K fixed nodes and with 1 sec time - nonsense? I run 100 10movers with 30s and 4 core with these results:

SF 9.9. mate 86 shortest mate 71
SF 24.9. mate 84 shortest mate 65

And shortest mate is important or do You prefer syzygy style +128 mate .

[yurikvelo]

And shortest mate is important or do You prefer syzygy style +128 mate .

fishtest is not Syzygy-capable and games are adjudicated at +5.0 or so

[Evert]

It seems unlikely that the patch is intended to find shorter mates. It's more likely that the patch ameliorates the effect of delaying tactics (you don't actually prevent the mate, you just push it past the horizon with delaying tactics that are ultimately a waste of time).
There is no Elo difference between preferring a long mate or a short mate anyway, provided you actually deliver mate eventually: in both cases you win the game.

[yurikvelo]

It seems unlikely that the patch is intended to find shorter mates.

https://github.com/lucabrivio/Stockfish ... ea9661bb3e

It is claimed increase in any DTM found at cost of regression in shortest DTM found (both on fixed nodes and fixed time)

[Evert]

It seems unlikely that the patch is intended to find shorter mates.

https://github.com/lucabrivio/Stockfish ... ea9661bb3e

It is claimed increase in any DTM found at cost of regression in shortest DTM found (both on fixed nodes and fixed time)

Proofs my point: it does not find shorter mates (but it does find more mates).

[Joerg Oster]

The patch "allowing singular extension in mate positions" was tested with 200K fixed nodes and with 1 sec time - nonsense? I run 100 10movers with 30s and 4 core with these results:

SF 9.9. mate 86 shortest mate 71
SF 24.9. mate 84 shortest mate 65

And shortest mate is important or do You prefer syzygy style +128 mate .

What do these positions look like?
A mate in 10 should be resolved within seconds, unless there are some issues like zugzwang involved.

In general, if you run with more than 1 thread, results are not deterministic.
Several runs may be needed.

I can provide some counterexamples.

A basic KRK mate in 14
[d]8/8/8/3k4/8/8/8/R3K3 w - - 0 1

Code: Select all

master
info depth 52 seldepth 38 multipv 1 score mate 14 nodes 15819394 nps 2603158 hashfull 167 tbhits 0 time 6077 pv a1a5 d5c6 e1d2 c6b6 a5e5 b6c7 d2c3 c7d6 c3d4 d6c6 e5d5 c6b6 d5c5 b6a6 d4c4 a6b6 c4b4 b6a6 c5b5 a6a7 b4a5 a7a8 a5b6 a8b8 b5c5 b8a8 c5c8

alwaysSingular
info depth 41 seldepth 40 multipv 1 score mate 14 nodes 10060706 nps 2455627 hashfull 206 tbhits 0 time 4097 pv a1a5 d5c6 e1d2 c6b6 a5d5 b6c6 d5d3 c6c5 d2c3 c5b5 d3d5 b5b6 c3b4 b6c6 d5d4 c6b6 d4c4 b6a6 b4c5 a6b7 c5b5 b7a7 b5c6 a7a8 c6c7 a8a7 c4a4

Mate in 16
[d]8/6p1/7p/4k2P/8/2PK4/6P1/8 w - - 0 1

Code: Select all

master
info depth 49 seldepth 46 multipv 1 score mate 16 nodes 125057924 nps 2646448 hashfull 474 tbhits 0 time 47255 pv c3c4 e5e6 d3e4 e6d6 e4d4 d6e7 d4d5 e7d7 c4c5 d7c7 c5c6 c7b6 d5d6 b6b5 c6c7 b5c4 c7c8q c4d3 d6d5 g7g6 h5g6 h6h5 g6g7 d3e2 g7g8q e2f1 g8g3 h5h4 c8c4 f1g1 c4c1

alwaysSingular
info depth 42 seldepth 47 multipv 1 score mate 16 nodes 69582445 nps 2659879 hashfull 328 tbhits 0 time 26160 pv c3c4 e5e6 d3d4 e6d6 c4c5 d6e6 d4e4 e6d7 e4d5 d7c7 c5c6 c7b6 d5d6 b6b5 c6c7 b5c4 c7c8q c4d3 d6d5 d3e2 c8c2 e2e3 d5e5 g7g6 h5g6 h6h5 g6g7 h5h4 g7g8q h4h3 g8b3

[Joerg Oster]

It seems unlikely that the patch is intended to find shorter mates.

https://github.com/lucabrivio/Stockfish ... ea9661bb3e

It is claimed increase in any DTM found at cost of regression in shortest DTM found (both on fixed nodes and fixed time)

Proofs my point: it does not find shorter mates (but it does find more mates).

Well, for me it also helps to find fastest mates in shorter time.
See my response to the OP.

But basically this patch is more a fix of a fix.
If you're interested, you can find the whole conversation in the pull request.
https://github.com/official-stockfish/S ... h/pull/810

[Jouni]

I ran test originally with "slow" abrok compile. Also because of SMP I retested with totally different results. I also run additional 250 piece of 15-20 movers. Now it seems, that 24.9. is not worse than 9.9. if not much better! I will run some single core test tomorrow to verify my results.

[Joerg Oster]

I ran test originally with "slow" abrok compile. Also because of SMP I retested with totally different results. I also run additional 250 piece of 15-20 movers. Now it seems, that 24.9. is not worse than 9.9. if not much better! I will run some single core test tomorrow to verify my results.

Great. Looking forward to seeing your results.

[Jouni]

After some single core testing the patch seems to be OK! Sorry for too early conclusion .