Introducing a depth-dependent term to the LMR reduction formula

[FauziAkram]

Introducing a depth-dependent term to the LMR reduction formula.

Passed STC:
LLR: 2.95 (-2.94,2.94) <0.00,2.00>
Total: 118912 W: 30938 L: 30498 D: 57476
Ptnml(0-2): 393, 13962, 30315, 14384, 402
https://tests.stockfishchess.org/tests/view/678cf401d63764e34db49009

Passed LTC:
LLR: 2.94 (-2.94,2.94) <0.50,2.50>
Total: 88338 W: 22660 L: 22230 D: 43448
Ptnml(0-2): 71, 9776, 24042, 10212, 68
https://tests.stockfishchess.org/tests/view/678d3232d63764e34db4915e

bench: 1420562

[github-actions]

clang-format 18 needs to be run on this PR.
If you do not have clang-format installed, the maintainer will run it when merging.
For the exact version please see https://packages.ubuntu.com/noble/clang-format-18.

(execution 12856311113 / attempt 1)

[locutus2]

This has to be tested at VLTC how it remarks in the comment (which was not moved with the reduction rule, this should be done also or copied):

// These reduction adjustments have proven non-linear scaling.
// They are optimized to time controls of 180 + 1.8 and longer,
// so changing them or adding conditions that are similar requires
// tests at these types of time controls.

[FauziAkram]

These reduction adjustments have proven n

1. That was not requested for other similar patches, for example
   Tweak ttCapture reduction #5610
2. After the fractional LMR patch Introduce Fractional LMR #5667 (Which also was not requested to test at VLTC) the values were not optimized anymore for 180 + 1.8 TC , without mentioning that after so many VVLTC, all values in search are now optimized for VVLTC

Anyway waiting to hear from the maintainers their opinion.

[Disservin]

well uff i didn't really remember this comment, were there any patches merged after the vvltc tune which changed stuff there? was the comment really talking about all r 's ?

[locutus2]

@FauziAkram
You doesn't get what i meant. Only for two special reduction rules this have to be tested according to comment. Before you move one of this rules . The cases you mentioned are not affected by the comment (the fractional plies patch only replace 1 by 1024 because that is functional equivalent for this two rules).

Here the code before it was moved before pruning from which you see that exactly the ss->ttPv and PvNode rule have only this requirement (Important is also the last sentence at the end) Else the comment would make no sense.

        // These reduction adjustments have proven non-linear scaling.
        // They are optimized to time controls of 180 + 1.8 and longer,
        // so changing them or adding conditions that are similar requires
        // tests at these types of time controls.

        // Decrease reduction if position is or has been on the PV (~7 Elo)
        if (ss->ttPv)
            r -= 1037 + (ttData.value > alpha) * 965 + (ttData.depth >= depth) * 960;

        // Decrease reduction for PvNodes (~0 Elo on STC, ~2 Elo on LTC)
        if (PvNode)
            r -= 1018;

       // These reduction adjustments have no proven non-linear scaling

[FauziAkram]

I see, I submitted a VLTC test
And meanwhile I will also work on a PR to improve the comments for these 2 reductions, since now they are not near each other.

[locutus2]

@FauziAkram
Sorry, i see you have submitted the VLTC with the wrong hash size. It should be 196 (64*3) at least all other VLTC i have seen use this.