UCI extension: nodestime

[Desperado]

...
So your speed up trick yields to a game played with (almost) fixed number of nodes per move and you lose the usual decrease of time during the match.

I am not sure if this ( completely ) true because the node computation is proportional to the delivered time ( just scaled ).

If you have a time decrease per move like 1500ms 1420ms,1300ms... you
will have instead (eg) 150000,142000,130000 nodes. (real time numbers are about: 3000000, 2840000, 2600000 in that case, but proportional)

Of course, if you want to emulate a 60000ms game you might use a real time of factor n, but it has a proportional behaviour in game play.
Now, having the example of my post before, there would be a speedup of 20. So, to emulate a 60000ms game you would need a 1200s/game.
At this point we have a slight guess where a real 60s game would be different than a virtual 60s (1200s with speedup) game.

But for now i am not able to see how this effects the time management.
Of course if your time manager has different algorithms for 1200s than for 60s then there would be a difference. But that is not the problem of the NIT algorithm itself.

[mcostalba]

If you have a time decrease per move like 1500ms 1420ms,1300ms...

If you set the speed up to 1 you will have a time decrease per move like 1500ms 1420ms,1300ms.

But if you set the speed up to 20 you will have a time decrease per move like 1500ms, 1495ms, 1490ms....

If you set the speed up to 100 you will have a time decrease per move like 1500ms, 1499ms, 1498ms....

Hope this clarifies what I was talking about.

[Desperado]

If you have a time decrease per move like 1500ms 1420ms,1300ms...

If you set the speed up to 1 you will have a time decrease per move like 1500ms 1420ms,1300ms.

But if you set the speed up to 20 you will have a time decrease per move like 1500ms, 1495ms, 1490ms....

If you set the speed up to 100 you will have a time decrease per move like 1500ms, 1499ms, 1498ms....

Hope this clarifies what I was talking about.

Not really, because you can stretch it again by given more real time per game as i described it with my emulation example.

[mcostalba]

Not really, because you can stretch it again by given more real time per game as i described it with my emulation example.

Ok, now I understand better. Thanks. You increase TC according to speed factor.

But still the GUI does not take in account the time not used by the engine because steal by background activity.

For instance if GUI sends 10 seconds and engine uses just 1, but due to background activity, returns best move after 2 seconds, then the GUI at the next move sends 8 seconds and not 9 as it should be.

[mcostalba]

For instance if GUI sends 10 seconds and engine uses just 1, but due to background activity, returns best move after 2 seconds, then the GUI at the next move sends 8 seconds and not 9 as it should be.

Nevertheless your NIT idea gave me the starting hint to write what I think is the correct solution. I have run the extra mile and added in the engine a very simple GUI time manager emulator, so that available nodes are accounted correctly from move to move.

I have submitted a test to verify there are no big holes:

http://tests.stockfishchess.org/tests/v ... 02160ec41c

Also in this case, as in NIT, the solution does not requires changes in the GUI and is fully handled inside the engine.

[mcostalba]

I have submitted a test to verify there are no big holes:

There was a bug in the code, the correct test is this one:

https://github.com/mcostalba/Stockfish/tree/nodestime

Preliminary results are encouraging, the standard deviation of the results with nodestime seems lower than in standard TC, but samples are definitely too few to draw any conclusion, I am going to schedule more tests...