Remove material imbalance from nnue eval adjustment

[gahtan-syarif]

Passed non-reg STC:
https://tests.stockfishchess.org/tests/view/65fdf11f0ec64f0526c52b57
LLR: 2.93 (-2.94,2.94) <-1.75,0.25>
Total: 76480 W: 19893 L: 19712 D: 36875
Ptnml(0-2): 339, 9107, 19157, 9308, 329

Passed non-reg LTC:
https://tests.stockfishchess.org/tests/view/65fee22e0ec64f0526c53885
LLR: 2.95 (-2.94,2.94) <-1.75,0.25>
Total: 150948 W: 38078 L: 37988 D: 74882
Ptnml(0-2): 111, 16997, 41148, 17127, 91

Bench: 1709945

[github-actions]

clang-format 17 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/mantic/clang-format-17.

(execution 8425803864 / attempt 1)

[Lowform]

Seems to me it could be rewritten like:

const auto adjustEval = [&](int optDiv, int nnueDiv, int pawnCountConstant, int pawnCountMul,
                                int npmConstant, int evalDiv, int shufflingConstant,
                                int shufflingDiv) {
        // Blend optimism and eval with nnue complexity and material imbalance
        optimism += optimism * (nnueComplexity + std::abs(simpleEval - nnue)) / optDiv;
        nnue -= nnue * nnueComplexity / nnueDiv;// no parenthesis and 3/5 in nnueDiv argument

        int npm = pos.non_pawn_material() / 64;
        v       = (nnue * (npm + pawnCountConstant + pawnCountMul * pos.count<PAWN>())
             + optimism * (npmConstant + npm))
          / evalDiv;

        // Damp down the evaluation linearly when shuffling
        int shuffling = pos.rule50_count();
        v             = v * (shufflingConstant - shuffling) / shufflingDiv;
    };

    if (!smallNet)
        adjustEval(513, 19437, 919, 11, 145, 1036, 178, 204);// 32395*3/5 = 19437
    else if (psqtOnly)
        adjustEval(517,  19714 , 908, 7, 155, 1019, 224, 238);// 32857*3/5 = 19714.2
    else
        adjustEval(499,  19676, 903, 9, 147, 1067, 208, 211);// 32793*3/5 = 19675.8

I'm uncertain about the computational difference in putting 5/3 in nnueDiv (still learning coding), but it seems logical to me. Apologies for the noise if it's nonsense.

[Lowform]

Also, don't know if above comment needs an update for not blending material imbalance into nnue. v has optimism and optimism has std::abs(simpleEval - nnue).

[gahtan-syarif]

Seems to me it could be rewritten like:

const auto adjustEval = [&](int optDiv, int nnueDiv, int pawnCountConstant, int pawnCountMul,
                                int npmConstant, int evalDiv, int shufflingConstant,
                                int shufflingDiv) {
        // Blend optimism and eval with nnue complexity and material imbalance
        optimism += optimism * (nnueComplexity + std::abs(simpleEval - nnue)) / optDiv;
        nnue -= nnue * nnueComplexity / nnueDiv;// no parenthesis and 3/5 in nnueDiv argument

        int npm = pos.non_pawn_material() / 64;
        v       = (nnue * (npm + pawnCountConstant + pawnCountMul * pos.count<PAWN>())
             + optimism * (npmConstant + npm))
          / evalDiv;

        // Damp down the evaluation linearly when shuffling
        int shuffling = pos.rule50_count();
        v             = v * (shufflingConstant - shuffling) / shufflingDiv;
    };

    if (!smallNet)
        adjustEval(513, 19437, 919, 11, 145, 1036, 178, 204);// 32395*3/5 = 19437
    else if (psqtOnly)
        adjustEval(517,  19714 , 908, 7, 155, 1019, 224, 238);// 32857*3/5 = 19714.2
    else
        adjustEval(499,  19676, 903, 9, 147, 1067, 208, 211);// 32793*3/5 = 19675.8

I'm uncertain about the computational difference in putting 5/3 in nnueDiv (still learning coding), but it seems logical to me. Apologies for the noise if it's nonsense.

i was planning to reformat it like this but it results in bench change due to idiv, so ill have to run a new set of tests. for now the multiplier constant is enough to achieve my goal which is to remove the material imbalance scaling from nnue