Agressive increasing of lower bound.

[locutus2]

After a new best move was found at a PV node increase the lower bound at least to the middle of the initial search window (instead only to the new best value).

Thanks also to Kian which inspired me with his first tests about the base idea.

Passed STC:
LLR: 2.94 (-2.94,2.94) <0.00,2.50>
Total: 26792 W: 7158 L: 6902 D: 12732
Ptnml(0-2): 95, 2905, 7163, 3115, 118
https://tests.stockfishchess.org/tests/view/62631482fe69c0c878b83277

Passed LTC:
LLR: 2.94 (-2.94,2.94) <0.50,3.00>
Total: 36928 W: 9923 L: 9651 D: 17354
Ptnml(0-2): 25, 3623, 10897, 3893, 26
https://tests.stockfishchess.org/tests/view/62638a46fe69c0c878b84591

Bench: 7296489

[locutus2]

I have also another variation of this idea which passes also LTC this is complexer and passed slower than the PR.
https://tests.stockfishchess.org/tests/view/6262d0fdfe69c0c878b82726

The only question for me is how this scales with greater depth because it raises alpha always to the middle of the window for the first found best move. That is the difference to the other passed version where this is lowered with greater depth by the beta - 3*depth term (so the effect should be vanish with greater depths).

EDIT:
so should we do some verification at VLTC?

[locutus2]

I try now a more safer variant of this PR where we have to reach at least the tt value before do agressive increasing alpha:
https://tests.stockfishchess.org/tests/view/62645519c77167c0dd808d20

EDIT:
And here asecond try with depth weighted approach. So the agressive alpha increase is lowered with depth:
https://tests.stockfishchess.org/tests/view/6264597fc77167c0dd808deb

[vondele]

@locutus2 thanks, interesting. I don't think we should test this at VLTC unless you're particularly concerned.

I see you have a few other patches running, I suggest we move ahead merging this one and the follow up patches are tested against this simple variant, OK?

[vondele]

Actually, I think I found a problem with this patch, it affects mate finding quite significantly.
Found best mates:

    master  2323
     patch  1690

for mates, differences in score of 1 are important, and this scheme might make it difficult to find those.
Testing a variant with if (beta < VALUE_TB_WIN_IN_MAX_PLY && initialAlpha > VALUE_TB_LOSS_IN_MAX_PLY)
yields

    master  2323
     patch  2342

so issue fixed. It is a functional change (albeit small), but in that case I would ask to retest the patch once more (directly at LTC) with this change in place.

[locutus2]

@vondele
Ok, if you have no problems i will retest your fixed version and do further tests on top of this (if this hopefully passes).

EDIT:
Here is the retest with your fix: https://tests.stockfishchess.org/tests/view/6264fcea60f74bf0dfac5067

[jhellis3]

The more concerning part is it doesn't make logical sense. If one considers what it is doing, preventing soft fail-lows & stabilizing search, it is not unreasonable. However, the method by which this is achieved is rather dubious IMO.

[jhellis3]

Was thinking about this some more, and it occurred to me that the benefit may have little to do with the bound and/or move selection. It is possible that by maintaining an alpha higher than the searched value while the score is within the window, we are avoiding increments to bestMoveChanges. This alters time management such that in situations where the score difference is likely relatively small (within the window), SF will thus spend less time.

I would suggest testing the restricting of bestMoveChanges increment to fail highs and situations where the primary move scores less than alpha. If that passes, it is likely the source of the Elo gain anyway, and we don't end up with a situation where we have unreasonably high alphas.

[locutus2]

@vondele
Surprisingly your mate fix seems to fail https://tests.stockfishchess.org/tests/view/6264fcea60f74bf0dfac5067.
So this topic seems really strange and dangerous. I propose not to commit this PR at least not in this form. I would close this PR or should we let it open for a while to investigate this topic?

[vondele]

I think we can close, I will not commit it in this form, but I see this PR triggered a few interesting experiments on fishtest already.