time management and position complexity

[tissatussa]

recently i saw a GitHub commit of the chess engine Simbelmyne (rating ~3000), see https://github.com/sroelants/simbelmyne/pull/272/commits/36b8d6833e541c56a7b40d9ad7f09b03798102b8 it's about "soft & hard time" concerning time control .. i wanted to share this with you, because i'm attracted to the idea, then i saw you already implemented such function, or is it the same ? Can you explain in words how it functions in practice and why you chose to use it ?

regarding time control i was also thinking about the "complexity of the position" - once i saw some function for that, someone created a value for this, but i forgot where i found it .. i think smart time control is very important, whatever the strength of the engine : when it fails to play the 'right' move in a 'crucial' position, the game may be lost while no good continuations can be found ..

i imagine it's hard to get your head around this, let it sink in.

[tissatussa]

another thing regarding this : when using the MultiPV function (mpv) of some engines, the cp score of the top-5 bestmoves at each search depth may be close - many moves are possible and at each following depth bestmove may have changed .. now here comes my idea : in such case another evaluation function could be used, one which distinguishes on different grounds. I'm not suggesting you should implement mpv (for this, or anyhow, although it's a nice addition), for me mpv is a way to better see all alternative moves and how they can be rejected at climbing depths.

[FedericoSaitta]

yes time management can be indeed very complex and the implementation I have Is very basic though I think it does the job for now. Hard time limit is the one you should not be exceeding, while a soft limit is put in place to make sure we dont just aimlessly go into a deeper search that will be stopped halfway through (at least in Aramis soft time limit is checked before starting new iterative deepening depth). You are right, this Implementation is very simple and does not take into account complexity of a position where spending maybe 1 extra second on a certain move would win you the game. I have seen around some time-management that considers how stable the evaluation result is as a way to estimate the complexity of the position and hence give more or less time to the engine to think. For now I think I have enough Improvements lined up that would contribute to the engine's play a lot more than time-management but one day I will definitely revisit this and look at more complex soft bound calculation but from my tests, my engine does not flag and does not have un-reasonable chunks of time left when the game ends.

another thing regarding this : when using the MultiPV function (mpv)... MPV is in my eyes a very advanced technique and I have no Idea how it works, and how the search and pruning are affected, I’m sure you can find someone more experienced than myself that will give you a good answer to your question

[tissatussa]

..MPV is in my eyes a very advanced technique and I have no Idea how it works, and how the search and pruning are affected, I’m sure you can find someone more experienced than myself that will give you a good answer to your question..

right .. but doesn't your engine have some top-(5) best-move-list internally ? I mean, during search when 'current bestmove' is replaced with a better one, the best-move-history list can be considered as such top-x ? Then, when bestmove changes (a lot) at climbing depth, another evaluation can (also) be consulted, maybe leading to a more clear bestmove selection in such position. I'm not aware someone has ever implemented such idea .. special tuning is needed to develop this evaluation setup, and probably many test positions, but i think it can be done.

[tissatussa]

btw. i understand you consider other code issues more important at this moment in time.

[FedericoSaitta]

I would need to look into this again, but yes this would be possible to keep track of the best moves overall. though because of pruning and alpha beta keeping track of if a move is better than another, and not by how much (null-window search) some of the scores given to the second, third, fourth etc. moves might be completely underestimating how truly bad or neutral they are. I’m not sure how top engines accurately score moves other than the first one, might be worth looking into it