with or without increment?

[lucasart]

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 ?

[BB+]

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?

[hyatt]

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.