with or without increment?

Code, algorithms, languages, construction...

with or without increment?

Postby lucasart » Sun May 24, 2015 11:24 am

I have noticed something rather odd, perhaps it is SF specific due to how the time management works:
  • At very short tc (eg. 3"+0.03"), testing with increment is better. More precisely, SF playing in X"+X/100" beats SF playing in Y"+0", where Y is calibrated to give the same throughput. In other words, to better use testing time, one should use an increment (inc=base/100 was better than no increment, 100 is just a random choice I like, didn't experience with any other).
  • At longer tc (eg. 10"+0.1"), things even out, and maybe the no increment fares slightly better (hardly mesurable).
Anyone else done some research on that ?
"Talk is cheap. Show me the code." -- Linus Torvalds.
lucasart
 
Posts: 197
Joined: Mon Dec 17, 2012 1:09 pm

Re: with or without increment?

Postby BB+ » Sun May 24, 2015 10:29 pm

I would think any such behaviour would be highly engine-dependent. I take it that the calibration is so that the average with-increment game takes the same amount of time as the without-increment in self-play. Do they also have the same average number of moves? Are the sizes (in SF) of limits.inc[us] versus moveOverhead relevant?
BB+
 
Posts: 1484
Joined: Thu Jun 10, 2010 4:26 am

Re: with or without increment?

Postby hyatt » Mon May 25, 2015 1:43 am

lucasart wrote:I have noticed something rather odd, perhaps it is SF specific due to how the time management works:
  • At very short tc (eg. 3"+0.03"), testing with increment is better. More precisely, SF playing in X"+X/100" beats SF playing in Y"+0", where Y is calibrated to give the same throughput. In other words, to better use testing time, one should use an increment (inc=base/100 was better than no increment, 100 is just a random choice I like, didn't experience with any other).
  • At longer tc (eg. 10"+0.1"), things even out, and maybe the no increment fares slightly better (hardly mesurable).
Anyone else done some research on that ?



Most often this is a direct reflection of how testing is done. If you test with incs, you will likely tweak/tune the time allocation code over time to optimize for inc games. I've pointed out exactly the same problem with pondering. Most test with ponder=off, and when they chime in with ponder=on, things don't go as well as expected, they often use too little time.
hyatt
 
Posts: 1242
Joined: Thu Jun 10, 2010 2:13 am
Location: University of Alabama at Birmingham


Return to Programming and Technical Discussions

Who is online

Users browsing this forum: No registered users and 2 guests

cron