ambiguous UCI protocol question

[Gian-Carlo Pascutto]

Are you sure that Fischer time adds time before the move?

I'm not sure, but according to wikipedia it does. Of course that doesn't make it so.

Ok, you learn something new every day

[Sven]

Isn't it possible to simply test what UCI GUIs do really send as wtime/btime for the very first move of the game if you specify 10+1 time control?

I don't have access to many UCI GUI's, and there is no guarantee that the ones I would be looking at are correct. I'm a bit anal about making software with bugs on purpose for compatibility, I don't want to do this. I want to know what the right way is, not how some GUI implements it.

It was not my intent to imply that you should make software with bugs on purpose for compatibility. It was just a proposal to find out what the "most important" UCI GUIs will do. If they add the increment prior to the very first move of the game already then everything is fine. If they don't then there are two choices for an engine author:

a) add the increment that is probably missing for the very first move of the game in an intelligent way "somehow", assuming that the GUI will do that implicitly "somehow" later, and accepting that the GUI might in fact not do so, possibly causing time losses at some point later;

b) do not add any increment by yourself but rely completely on the reported time data, which is the defensive style.

I guess you won't ever try choice a), would you? So I believe there is really zero choice for you, and the only thing that should be clarified is what the GUIs really do and whether this is correct or not w.r.t. the FIDE rules.

And as already mentioned in another post, this is not essentially a UCI issue only.

If we find out, however, that "all GUIs" are handling this wrong then what will happen?

Sven

[metax]

Interesting point... not just for UCI

I've just corrected a time loss bug at fast time controls, because I was allocating time/30 + inc, and loosing on time e.g for time control 10s + 1s

The engine would have 0.3s left, and allocate 1.03s for the move, and lose on time, ( in winboard ) - so I think there the time was being added after the move. Since removing the + inc the problem has gone.

I've just tried WB to check, and it adds the inc after the move is played.

I had this problem, too, and with some more GUIs (Shredder Classic and Arena). They all add the inc after the move. I solved this by simply adding a

Code: Select all

searchTime = min(searchTime, timeLeft - buffer);

after the actual calculation of the search time. Just removing the +inc seemed not good because for high increments like 1+10 the engine would play very fast in the first moves as it could not 'see' the increment, which would result in bad play.


@Sven: Your two choices are not the only ones...

[Don]

Isn't it possible to simply test what UCI GUIs do really send as wtime/btime for the very first move of the game if you specify 10+1 time control?

I don't have access to many UCI GUI's, and there is no guarantee that the ones I would be looking at are correct. I'm a bit anal about making software with bugs on purpose for compatibility, I don't want to do this. I want to know what the right way is, not how some GUI implements it.

It was not my intent to imply that you should make software with bugs on purpose for compatibility. It was just a proposal to find out what the "most important" UCI GUIs will do. If they add the increment prior to the very first move of the game already then everything is fine. If they don't then there are two choices for an engine author:

a) add the increment that is probably missing for the very first move of the game in an intelligent way "somehow", assuming that the GUI will do that implicitly "somehow" later, and accepting that the GUI might in fact not do so, possibly causing time losses at some point later;

b) do not add any increment by yourself but rely completely on the reported time data, which is the defensive style.

I guess you won't ever try choice a), would you? So I believe there is really zero choice for you, and the only thing that should be clarified is what the GUIs really do and whether this is correct or not w.r.t. the FIDE rules.

And as already mentioned in another post, this is not essentially a UCI issue only.

If we find out, however, that "all GUIs" are handling this wrong then what will happen?

Sven

I guess we should find out what the intended way is, and presumably the Shredder GUI would be the reference implementation.

If it turns out that most of the "important" GUIs are doing it wrong then we are between a rock and a hard place. It should not be that way, that improper implementations of things define the standards. I would suggest that the ill defined behavior is identified and advertised and that with new releases of the GUI products the fixes should be made.

But we are jumping the gun, maybe there is no problem. I think I will see if I can get in touch with Stefan.

Don

[Don]

So what if the main time control is set to zero? You could have a time control of 00:00 + 00:01 in which case would you lose by time forfeit no matter how quickly you played the first move?

That's why I think the Fischer rule is logical. The increment is supposed to protect you from EVER having to make a move instantly the way I understand it.

So there are really 2 primary questions:

1. What is the UCI rule about how this is handled.
2. Does any particular GUI implement the Fischer concept correctly.

Note that UCI would work in either case, we just need to get a definitive answer on which obeys the standard.



With the second issue, if user interfaces have it wrong and actually add the increment AFTER the move, then it's a big fat bug. There is no question about this one.

So a particular GUI could have either or both of these wrong. For the GUI there are 2 issues, does it do UCI correct and does it do Fischer correct.

I guess these questions extend to the engines too.

Here is a test. Set your GUI to 0 + 10 and see if it loses on time on the first move.

By the way, I sent an email to Stefan asking him about these 2 issues. Hopefully he will respond.

[metax]

So what if the main time control is set to zero? You could have a time control of 00:00 + 00:01 in which case would you lose by time forfeit no matter how quickly you played the first move?

That's why I think the Fischer rule is logical. The increment is supposed to protect you from EVER having to make a move instantly the way I understand it.

So there are really 2 primary questions:

1. What is the UCI rule about how this is handled.
2. Does any particular GUI implement the Fischer concept correctly.

Note that UCI would work in either case, we just need to get a definitive answer on which obeys the standard.



With the second issue, if user interfaces have it wrong and actually add the increment AFTER the move, then it's a big fat bug. There is no question about this one.

So a particular GUI could have either or both of these wrong. For the GUI there are 2 issues, does it do UCI correct and does it do Fischer correct.

I guess these questions extend to the engines too.

Here is a test. Set your GUI to 0 + 10 and see if it loses on time on the first move.

By the way, I sent an email to Stefan asking him about these 2 issues. Hopefully he will respond.

Most GUIs I know simply set the starting time to 0:10 then instead of 0:00. So if you try to play 0+1 then you actually play 0:10+1.

[Don]

So what if the main time control is set to zero? You could have a time control of 00:00 + 00:01 in which case would you lose by time forfeit no matter how quickly you played the first move?

That's why I think the Fischer rule is logical. The increment is supposed to protect you from EVER having to make a move instantly the way I understand it.

So there are really 2 primary questions:

1. What is the UCI rule about how this is handled.
2. Does any particular GUI implement the Fischer concept correctly.

Note that UCI would work in either case, we just need to get a definitive answer on which obeys the standard.



With the second issue, if user interfaces have it wrong and actually add the increment AFTER the move, then it's a big fat bug. There is no question about this one.

So a particular GUI could have either or both of these wrong. For the GUI there are 2 issues, does it do UCI correct and does it do Fischer correct.

I guess these questions extend to the engines too.

Here is a test. Set your GUI to 0 + 10 and see if it loses on time on the first move.

By the way, I sent an email to Stefan asking him about these 2 issues. Hopefully he will respond.

Most GUIs I know simply set the starting time to 0:10 then instead of 0:00. So if you try to play 0+1 then you actually play 0:10+1.

That is really ugly if it's really what is happening. Are you sure they are not just adding the increment to the main time? If you set the time control to 5 minutes + 10 seconds for instance, the clock should start with 05:10 and count down from there.

[MattieShoes]

So what if the main time control is set to zero? You could have a time control of 00:00 + 00:01 in which case would you lose by time forfeit no matter how quickly you played the first move?

That's why I think the Fischer rule is logical. The increment is supposed to protect you from EVER having to make a move instantly the way I understand it.

So there are really 2 primary questions:

1. What is the UCI rule about how this is handled.
2. Does any particular GUI implement the Fischer concept correctly.

Note that UCI would work in either case, we just need to get a definitive answer on which obeys the standard.



With the second issue, if user interfaces have it wrong and actually add the increment AFTER the move, then it's a big fat bug. There is no question about this one.

So a particular GUI could have either or both of these wrong. For the GUI there are 2 issues, does it do UCI correct and does it do Fischer correct.

I guess these questions extend to the engines too.

Here is a test. Set your GUI to 0 + 10 and see if it loses on time on the first move.

By the way, I sent an email to Stefan asking him about these 2 issues. Hopefully he will respond.

Most GUIs I know simply set the starting time to 0:10 then instead of 0:00. So if you try to play 0+1 then you actually play 0:10+1.

That is really ugly if it's really what is happening. Are you sure they are not just adding the increment to the main time? If you set the time control to 5 minutes + 10 seconds for instance, the clock should start with 05:10 and count down from there.

I have no idea what fischer intended, but a time control of "0 1" is 0:10 plus 1 sec/move on chess servers like FICS. They don't add the increment on move 1, but the clock doesn't start either. After that, increment is added at the end of a move, so no moves need to be made instantly.

[metax]

That is really ugly if it's really what is happening. Are you sure they are not just adding the increment to the main time? If you set the time control to 5 minutes + 10 seconds for instance, the clock should start with 05:10 and count down from there.

No, if you set the clock to 0+1, it will actually be 0:10+1 with the increment added at the end at the move. As far as I remember (can't test it here), Shredder Classic and Fritz do this.
Arena 2.0.1 implements this a bit more correctly, but not quite. If you set the clock to 0+x, it will start at x seconds and then add the increment _after_ every move but the first. If you set it to y+x and y != 0, it will do the same as all the other GUIs: set the clock to y (but not y+x which would be correct!) and add the increment after every move, also the first.

Hope this is understandable.