mcostalba wrote:I am not sure if this ( completely ) true because the node computation is proportional to the delivered time ( just scaled ).Desperado wrote: ...
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.
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.
UCI extension: nodestime
Moderators: hgm, Rebel, chrisw
-
- Posts: 879
- Joined: Mon Dec 15, 2008 11:45 am
Re: UCI extension: nodestime
-
- Posts: 2684
- Joined: Sat Jun 14, 2008 9:17 pm
Re: UCI extension: nodestime
If you set the speed up to 1 you will have a time decrease per move like 1500ms 1420ms,1300ms.Desperado wrote: If you 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.
-
- Posts: 879
- Joined: Mon Dec 15, 2008 11:45 am
Re: UCI extension: nodestime
Not really, because you can stretch it again by given more real time per game as i described it with my emulation example.mcostalba wrote:If you set the speed up to 1 you will have a time decrease per move like 1500ms 1420ms,1300ms.Desperado wrote: If you 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.
-
- Posts: 2684
- Joined: Sat Jun 14, 2008 9:17 pm
Re: UCI extension: nodestime
Ok, now I understand better. Thanks. You increase TC according to speed factor.Desperado wrote: Not really, because you can stretch it again by given more real time per game as i described it with my emulation example.
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.
-
- Posts: 2684
- Joined: Sat Jun 14, 2008 9:17 pm
Re: UCI extension: nodestime
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.mcostalba wrote: 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.
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.
-
- Posts: 2684
- Joined: Sat Jun 14, 2008 9:17 pm
Re: UCI extension: nodestime
There was a bug in the code, the correct test is this one:mcostalba wrote: I have submitted a test to verify there are no big holes:
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...