Simplification of TM declaration of timeLeft, and improvement of timeleft max() function

[TierynnB]

Declared timeLeft as a double, as it was always casting to a double anyway. and instead of defaulting timeleft to '1' in the scenario where
limits.time[us] + limits.inc[us] * (mtg - 1) - moveOverhead * mtg)
was less than 0, default to remaining time.

passed STC regression
https://tests.stockfishchess.org/tests/view/65d283751d8e83c78bfd9534

LTC regression
https://tests.stockfishchess.org/tests/view/65d32d7f1d8e83c78bfda1a2

and made a significant improvement in Sudden Death 10 sec.
https://tests.stockfishchess.org/tests/live_elo/65d65c061d8e83c78bfddb1a

[vondele]

In the future, please include the actual result from the test in the PR / commit message, thanks!

I think a side effect of this PR is that there might be a bit more time losses. I.e. while previously in sudden death we moved as quickly as possible if time becomes small compared to the move overheads assumed, now we basically, decide to ignore the move overhead. Seemingly, the extra time (and thus quality of play) offset the extra losses.

[vondele]

This could also impact #4000 I'll schedule a test: https://tests.stockfishchess.org/tests/view/65e495d4416ecd92c162a198

[TierynnB]

Yeah in retrospect, I think my intent was to set it to limits.time[us] only when that equation resolved to less than zero. Not all the time. That way it only uses limits.time[us] as the remaining time approaches zero, throughout the entire game.

Somehow I must have misunderstood how that max() function worked.

I think this is wrong, and should be rejected. I have some ideas to improve it though. That test doesn’t look to good anyway lol.

[TierynnB]

Or as remaining time approaches zero like this, reduce the move horizon to like 5 (or some small number) instead of 50. Basically right now, if there’s less than 500ms left in the game, it doesn’t use any of that time effectively and just picks the first move it can.

ill have a think about it. I’m not sure what the normal polite approach is, do I close or do I let you reject this PR? Since it’s kinda in your scope now if that makes sense .

[vondele]

since the additional test is failing, I think it is indeed best to close it. Let me, politely, do it :-) (but either way works). The sudden death improvement is definitely interesting, and there might be some gains to be extracted from playing with these test cases.