More low quality games or few better quality games?

[swami]

Ofcourse, Fair Enough. But with the noise level on the forum soon after any engine gets released, and their curiosity to know the ratings, I thought they are interested in stats rather than games, i know there are some who check games as well as stats.

People certainly want a rating for a new engine as fast as possible, that is where blitz is perfect. CEGT's medium 40/20 on an X2 4200+ is a very good compromise, reasonable quality games and they can be churned out quite quickly. Our 40/40 on X2 4600+ is really difficult for quick results, and indeed we are normally a little slow to get statistically valid results for new engines. But we get there in the end (usually...)

well, thats good. keep doing it, since you guys have faster hardwares, then longer time controls should give programmers of the engines good idea of where the weakness is. Others are curious- to- know- the- ratings and stats people.

[swami]

When you run fast games, I think it adds a bit more randomness, and requires that you check the results more carefully (you will see lots of losses for time, for instance).

Now, the big problem here is that slow games take a long time, and nobody has the patience for it.

I hardly see any losses on time, engines with bugs or the one that has poor time management(smarthink 0.17a for example) lose on time.A lot of engines respond well with time, I'd estimate it to be >90% engines that respond well with time.

As Prof.Dr.Robert Hyatt once said, one needs to run 1000,2000 games to get the very accurate engine ratings....

[Tony Thomas]

When you run fast games, I think it adds a bit more randomness, and requires that you check the results more carefully (you will see lots of losses for time, for instance).

Now, the big problem here is that slow games take a long time, and nobody has the patience for it.

I hardly see any losses on time, engines with bugs or the one that has poor time management(smarthink 0.17a for example) lose on time.A lot of engines respond well with time, I'd estimate it to be >90% engines that respond well with time.

As Prof.Dr.Robert Hyatt once said, one needs to run 1000,2000 games to get the very accurate engine ratings....

Yes, it is true that we get very few time losses at our time control. Also, most of the top engines never lose on time. It's mainly weak engines, or a beta version of a mid strength engine with some new algorithm that loses on time once in a while. I had posted a list a while back, so far these are all the engines that loses on time under my time controls currently. Note that most of the time after my bug reports the authors release a fix version, so they are taken off the list.

Code: Select all

Program              Loses 

Surprise 4.3 beta 13 xx x
Alex 1.85            xxxxxxxx 
Amundesen0.65        xxx
Asterisk 0.6         x 
Biglion 2.23w        xxx 
Dmitri 1.47wb        x 
Lodocase05.01.08     x 
Eden 0..0.13 JA        x

[Ovyron]

I know you want to build up a good number of games reasonably quickly.
If I was wanting to do that, I'd go for 40 moves in 5 minutes repeating, but 3 minutes + a 10 or 15 second increment would be the fastest I'd use.

Thanks. But 40/5 repeating is the equivalent of 3' + 3" for a 40 move game and 3' + 5(.25)" for a 80 moves game; since most games are expected to end within that margin I'm confused as to why an increment of at least 10 seconds is needed? (By 40/5 we'd be expecting a move every 7.5 seconds on average?)

I've tried 40/5 and disliked it. Mainly because most engines don't time manage these 40 moves very well. Slow moving engines play the last moves before the sudden 5 minute bonus a bit faster than the first moves after this bonus, disrupting their game, while fast moving engines play too fast regardless, but I don't think that having to wait 40 moves for a bonus helps any.

40 moves on x looks like being a big Fischer clock in where you get a big bonus every 40 moves, but I think that getting the same bonus (in small parts) gradually, each move is better. It could be interesting to know why the rating lists use 40/x, though. And another, what's the difference between 40/40 and 1/1? (One move in one minute.)

Meanwhile, I'm going to listen to Dann Corbit:

But for the bottom line, I would say:
"Do exactly what _you_ want to do."

And go with the average of a 1' + 7" time control (The equivalent of playing 40/5, with one extra minute and more like a 40/4.667...)

Thanks everyone!

[David Dahlem]

I know you want to build up a good number of games reasonably quickly.
If I was wanting to do that, I'd go for 40 moves in 5 minutes repeating, but 3 minutes + a 10 or 15 second increment would be the fastest I'd use.

Thanks. But 40/5 repeating is the equivalent of 3' + 3" for a 40 move game and 3' + 5(.25)" for a 80 moves game; since most games are expected to end within that margin I'm confused as to why an increment of at least 10 seconds is needed? (By 40/5 we'd be expecting a move every 7.5 seconds on average?)

I've tried 40/5 and disliked it. Mainly because most engines don't time manage these 40 moves very well. Slow moving engines play the last moves before the sudden 5 minute bonus a bit faster than the first moves after this bonus, disrupting their game, while fast moving engines play too fast regardless, but I don't think that having to wait 40 moves for a bonus helps any.

40 moves on x looks like being a big Fischer clock in where you get a big bonus every 40 moves, but I think that getting the same bonus (in small parts) gradually, each move is better. It could be interesting to know why the rating lists use 40/x, though. And another, what's the difference between 40/40 and 1/1? (One move in one minute.)

Meanwhile, I'm going to listen to Dann Corbit:

But for the bottom line, I would say:
"Do exactly what _you_ want to do."

And go with the average of a 1' + 7" time control (The equivalent of playing 40/5, with one extra minute and more like a 40/4.667...)

Thanks everyone!

Each engine manages time differently, so it all comes down to how each engine is programmed to manage each time control. I've seen engines that don't manage increment effectively, or sometimes even ignore the increment, but most engines do a fair job with 40/5 type time controls, so i hardly ever use Fischer time controls.

Regards
Dave

[Yarget]

I've seen engines that don't manage increment effectively, or sometimes even ignore the increment, but most engines do a fair job with 40/5 type time controls, so i hardly ever use Fischer time controls.

This is also my experience. When I was testing for the CSS SMP Ratinglist we used the 10+10 timecontrol. A couple of engines didn't know how to deal with this increment and especially Junior was a disaster. It was not unusual to see Junior losing a game (and not only short games) in which it still had 6 or 7 minutes left! On the opposite, engines like Zappa and Shredder were doing fine with the increment and they had (and have) the ability to spend more time in critical situations in the middlegame and then increase the movingspeed in an often decided endgame.

Generally the engines are feeling more comfortable with the more uncomplicated X moves in Y minutes. Right now I'm doing some tests with the 40/4 timecontrol:

http://64.68.157.89/forum/viewtopic.php?t=18891

It's working very fine. If you Ulysses (like me) are running some kind of special tests then I would advice you to use a timecontrol which is represented by CEGT, CCRL or SSDF (40/4, 40/20, 40/40 and so on). Then you can use the "official" ratinglists as a kind of referencelist and compare that one with your own results.

Speaking of timemanagement I'll never forget Saitek Stratos. I tested that chesscomputer for SSDF many years ago (40/120) and it was spending almost exactly 3 minutes for each move. It didn't matter if the position was simple or complicated. Even if Stratos had only one legal move you could be sure that it would spend 3 minutes before making the move!

Regards
Per

[Edsel Apostol]

From a programmer's point of view, I think engines could make use of their time more optimally using Fischer time controls than using "x moves in y minutes".

For example, in 40/time, at move 40, the engine might be only using its very small remaining time, while at move 41 it would usually have longer time to think. What if the critical move was move 40, it would have less time to think, when it arrived at move 41, it is too late, even when it has now much bigger time to think.

When using Fischer time controls, when the situation above happens, it can always allocate more time for move 40.

Another thing, if you graph the move number in x-axis and the time spent for each move in y-axis, you will notice that Fischer time controls have on average a smooth curve while "x moves in y minutes" is an ugly zigzag.

I myself prefer Fisher time controls, and I would rather see ratinglist that use it. It seems more logical to me.

[Spock]

I myself prefer Fisher time controls, and I would rather see ratinglist that use it. It seems more logical to me.

Yes, I prefer Fisher time controls also. No engine or human tournament ever uses a repeating time control to my knowledge. The only thing going for a repeating time control is maximum compatibility for all engines. Rarely, some engines may not support Fischer time.

[Ovyron]

I myself prefer Fisher time controls

Yes, I prefer Fisher time controls also.

I'm glad other persons like Fisher time controls more

By the way, is it "Fisher" or "Fischer"?

I thought it was Fischer but the ChessPartner GUI also refers to it as "Fisher:"

[Spock]

By the way, is it "Fisher" or "Fischer"?

I thought it was Fischer but the ChessPartner GUI also refers to it as "Fisher:"

Not sure....

With Fischer (or Fisher) time controls you see some interesting stuff. Like in my recent 90+30 small tournament, Scorpio 2.0 though it necessary on more than one occasion to spend 45 minutes on the first move out of book...