ChessGUI Timer Problem

[D Sceviour]

A new thread has been started as the discussion is beginning to tie up the ongoing author’s tournament.

ChessGUI sends a test-suite like setboard command to xboard based engines, instead of feeding the book moves to the engine. A big problem is that xboard engines do not read the move number from the setboard command. This creates a timer failure. Some xboard engines do not even use setboard. Suggestions are needed as to how to fix this.

The obvious solution is for the author of ChessGUI to fix the problem, but ChessGUI is not under development.

The next suggestion has been to require xboard engines to read the move number from the setboard command. There are multiple objections to this.

Another suggestion is to discard ChessGUI as an independent arbitrator of games, unless the author fixes the problem.

Graham Banks (who is doing a wonderful job) is trying use WB to UCI adaptors as a repair, but its usefulness is not clear at this time without further examination of the debug files. However, no one is going to bother with that if the GUI cannot be fixed.

[Evert]

ChessGUI sends a test-suite like setboard command to xboard based engines, instead of feeding the book moves to the engine.

I agree this is undesirable behaviour, but it raises a question: does it do the same in UCI mode (does it use "position fen ..." or does it use "position startpos ...")?
Note that UCI explicitly sends "movestogo", so using "position fen" does not lead to the problem described below.

A big problem is that xboard engines do not read the move number from the setboard command. This creates a timer failure.

I call this a bug.
Yes, I seem to have this same bug. I'll fix it.

Some xboard engines do not even use setboard.

Presumably they use edit instead? How does ChessGUI deal with engines that do not support setboard? Does it use edit, or does it feed them the list of moves?

The obvious solution is for the author of ChessGUI to fix the problem, but ChessGUI is not under development.

Is he willing/open to the suggestion of someone else taking over the code?

The next suggestion has been to require xboard engines to read the move number from the setboard command. There are multiple objections to this.

I see no reason to consider not using the move number anything other than a bug. I have no strong opinion on whether anyone should make it a priority to fix this though.

Another suggestion is to discard ChessGUI as an independent arbitrator of games, unless the author fixes the problem.

I have no definite opinion on this.

Graham Banks (who is doing a wonderful job) is trying use WB to UCI adaptors as a repair, but its usefulness is not clear at this time without further examination of the debug files. However, no one is going to bother with that if the GUI cannot be fixed.

Why would that not be useful? It's not idea, but it corrects the problem, right?

[D Sceviour]

ChessGUI sends a test-suite like setboard command to xboard based engines, instead of feeding the book moves to the engine.

I agree this is undesirable behaviour, but it raises a question: does it do the same in UCI mode (does it use "position fen ..." or does it use "position startpos ...")?
Note that UCI explicitly sends "movestogo", so using "position fen" does not lead to the problem described below.

ChessGUI sends the game moves to UCI in a startpos for example from a debug file:

Code: Select all

SendToEng2Time 0000000396886670 : Eng02 (Gogobello 1.0 64-bit) -> position startpos moves c2c4 b7b6 d2d4 e7e6 a2a3 c8b7 d4d5 g8f6 b1c3 g7g6 g1f3 f8g7 g2g3 e8g8 f1g2 e6d5 c4d5

A big problem is that xboard engines do not read the move number from the setboard command. This creates a timer failure.

I call this a bug.
Yes, I seem to have this same bug. I'll fix it.

You can, but remember there are other xboard authors who do not do this. As a courtesy, I may end up doing this myself. There may be still other timer problems such as ChessGUI’s questionable use of a timeout fudge number to prevent forfeits.

Some xboard engines do not even use setboard.

Presumably they use edit instead? How does ChessGUI deal with engines that do not support setboard? Does it use edit, or does it feed them the list of moves?

Apparently, a WB to UCI adapter is used on xboard engines that do not respond on the first try.

The obvious solution is for the author of ChessGUI to fix the problem, but ChessGUI is not under development.

Is he willing/open to the suggestion of someone else taking over the code?

Good question.

The next suggestion has been to require xboard engines to read the move number from the setboard command. There are multiple objections to this.

I see no reason to consider not using the move number anything other than a bug. I have no strong opinion on whether anyone should make it a priority to fix this though.

There are multiple objections to this:

(1) There are many WB engines that do not do this, and they are not under development.

(2) It violates Chess Engine Communication Protocol. There is no requirement in CECP for the move number to be read from the setboard command.

(3) IMHO, it violates the rules of chess because the 3-fold repetition and 50-move rule are not available.

(4) It gives a UCI engine an advantage because it has access to 3-fold repetition of position information on the opening move. Take for example if the opening position has two good moves, where one move is a repetition of the previous move. A UCI engine has the advantage of knowing one move is a repetition and can use half the time for the search that the xboard engine does. This would give an extremely unfair advantage, perhaps enough to win the game.

Graham Banks (who is doing a wonderful job) is trying use WB to UCI adaptors as a repair, but its usefulness is not clear at this time without further examination of the debug files. However, no one is going to bother with that if the GUI cannot be fixed.

Why would that not be useful? It's not idea, but it corrects the problem, right?

This is unknown without an exhaustive look at the debug files. It does not appear to help my engine, but that is not the issue. The issue is whether the xboard community is satisfied. There are other timer problems with ChessGUI in the debug files but I have not expanded on them yet.

[hgm]

ChessGUI sends the game moves to UCI in a startpos for example from a debug file:

Code: Select all

SendToEng2Time 0000000396886670 : Eng02 (Gogobello 1.0 64-bit) -> position startpos moves c2c4 b7b6 d2d4 e7e6 a2a3 c8b7 d4d5 g8f6 b1c3 g7g6 g1f3 f8g7 g2g3 e8g8 f1g2 e6d5 c4d5

This indeed seems to disadvantage XBoard engines, which do not have the whole game history available. Unless the lines end in an irreversible move, in which case the history is irrelevant.

You can, but remember there are other xboard authors who do not do this.

I have yet to meet one that does.

Presumably they use edit instead? How does ChessGUI deal with engines that do not support setboard? Does it use edit, or does it feed them the list of moves?

With the edit command no move number is transferred, however.

Is he willing/open to the suggestion of someone else taking over the code?

Good question.

He reported having destroyed the source code. So I guess this is not an option.

There are multiple objections to this:

(1) There are many WB engines that do not do this, and they are not under development.

(2) It violates Chess Engine Communication Protocol. There is no requirement in CECP for the move number to be read from the setboard command.

This is not true. CECP specs say a FEN is send. It does not specify what parts of the FEN should be ignored. Why shouldit be assumed by default that any part can be ignored?

[Sven]

The next suggestion has been to require xboard engines to read the move number from the setboard command. There are multiple objections to this.

I see no reason to consider not using the move number anything other than a bug. I have no strong opinion on whether anyone should make it a priority to fix this though.

There are multiple objections to this:

[...]

(2) It violates Chess Engine Communication Protocol. There is no requirement in CECP for the move number to be read from the setboard command.

I would say it more specific: as HGM states in another reply, of course the CECP does not advise us to ignore anything from the FEN. But the CECP spec tells us nothing that would indicate any specific role of the full move number that was given by FEN for the configuration of time control. It tells us, in the "Time control" section, that the "level" command informs us about the number of moves per session (for conventional time control) but there is no rule that states that this number of moves, when calculating the number of remaining moves to be made until more time will be added, shall be reduced according to the full move number specified for the starting position that is different from 1, or more precisely, 1 + K * MPS for any non-negative integer K. Also by intuition (but in line with the spec, in my view) I'd say that I get a certain amount of time for 40 moves (for example), so I can use it to think about 40 moves, not about (41 - full move number). A chess game that starts with a position different from the standard opening position is still a chess game where, with conventional time control, MPS moves shall be made within a given time. This is also how the tournament is announced: it is "40/40" (for instance), not "32/40". And if it were "32/40" then I would expect a "level 32 ....." command. Reducing MPS from 40 to 32 due to a given full move number of 9 would give me more time per move, but I can't accept that I shall take this additional time per move without any explicit advice by the spec, only to get wrecked some day by another GUI that uses setboard as well but does *not* add more time to my clock after 32 moves already!

(3) IMHO, it violates the rules of chess because the 3-fold repetition and 50-move rule are not available.

Agreed!

(4) It gives a UCI engine an advantage because it has access to 3-fold repetition of position information on the opening move. Take for example if the opening position has two good moves, where one move is a repetition of the previous move. A UCI engine has the advantage of knowing one move is a repetition and can use half the time for the search that the xboard engine does. This would give an extremely unfair advantage, perhaps enough to win the game.

Agreed!

What we need to understand, though, is why so many WB engines do not appear to have this problem when playing under ChessGUI, or at least why this problem has not been reported so far within many years of using ChessGUI with WB engines and GUI opening book. What makes the difference to engines like Schooner, Nemeton, or Francesca MAD that have been mentioned? I'll see whether I can find out the reason why my engine Jumbo does not suffer from this problem even though it ignores the full move number as well (like virtually all WB engines). Does using or not using the "time" command have any influence here? What else might be important?

[D Sceviour]

What we need to understand, though, is why so many WB engines do not appear to have this problem when playing under ChessGUI, or at least why this problem has not been reported so far within many years of using ChessGUI with WB engines and GUI opening book.

As yet, there is no xboard author that says he does not have a timer problem with ChessGUI.

[Evert]

ChessGUI sends the game moves to UCI in a startpos for example from a debug file:

Code: Select all

SendToEng2Time 0000000396886670 : Eng02 (Gogobello 1.0 64-bit) -> position startpos moves c2c4 b7b6 d2d4 e7e6 a2a3 c8b7 d4d5 g8f6 b1c3 g7g6 g1f3 f8g7 g2g3 e8g8 f1g2 e6d5 c4d5

Ok, then it's doing something different for CECP and UCI here. Which seems like an odd design decision, but anyway not something that helps us.

A big problem is that xboard engines do not read the move number from the setboard command. This creates a timer failure.

I call this a bug.
Yes, I seem to have this same bug. I'll fix it.

You can, but remember there are other xboard authors who do not do this. As a courtesy, I may end up doing this myself. There may be still other timer problems such as ChessGUI’s questionable use of a timeout fudge number to prevent forfeits.

Sure. I can only fix bugs in my own programs. As I said, I don't have a strong opinion on whether other people should fix this in their programs (and for abandoned programs, that would be hard).

Apparently, a WB to UCI adapter is used on xboard engines that do not respond on the first try.

Hmm... that doesn't really indicate how positions are sent in that case.
Note that using "edit" is rather pointless, since it doesn't let you pass the move number anyway. I can see possibilities here:

• Use edit. Doesn't help us, since it doesn't allow you to send move numbers anyway.
• Use setboard anyway, which is generally unhelpful/buggy behaviour
• Send the move list instead, as for UCI. This would actually solve the problem.

So in terms of work-arounds, it would help to know what it does here... although using UCI as a work-around also works.

(1) There are many WB engines that do not do this, and they are not under development.

Sure, it's not a fix for those. There, the only possible fix is to fix the GUI.

(2) It violates Chess Engine Communication Protocol. There is no requirement in CECP for the move number to be read from the setboard command.

Why would there need to be?
It says setboard passes a FEN string "as defined by the PGN spec", which has both a half-move and full-move counter. What other possible use is there for the full-move counter than to indicate the number of moves until the next time control?

(3) IMHO, it violates the rules of chess because the 3-fold repetition and 50-move rule are not available.

It does. When used for setting up opening positions, I don't think this is a major problem in practice (certainly the half-move clock is irrelevant, and anyway: that is in the FEN string as well) and going for a repetition straight out of the passed position (before any pawn pushes or exchanges) seems unlikely.

(4) It gives a UCI engine an advantage because it has access to 3-fold repetition of position information on the opening move. Take for example if the opening position has two good moves, where one move is a repetition of the previous move. A UCI engine has the advantage of knowing one move is a repetition and can use half the time for the search that the xboard engine does. This would give an extremely unfair advantage, perhaps enough to win the game.

The UCI engine knows it's a repetition, but since the moves were forced it has no relevant search results stored. If it incorrectly assumes that the second good move is a draw (because it is a repetition), it can also be badly wrong-footed.
I don't think this is so clear.

This is unknown without an exhaustive look at the debug files. It does not appear to help my engine, but that is not the issue. The issue is whether the xboard community is satisfied.

Not really, I'd prefer to see the GUI fixed. Barring that, as a work-around, I think this is ok-ish. Work-arounds are never ideal, of course.

[Evert]

Is he willing/open to the suggestion of someone else taking over the code?

Good question.

He reported having destroyed the source code. So I guess this is not an option.

That seems... excessive.

[Patrice Duhamel]

My engine support UCI and Xboard protocol, I think UCI mode is used in CCRL.

With Xboard protocol, I don't use the move number in setboard (I will fix this), but in the games I tried with ChessGUI I don't see a big problem, nothing that looks like your problem here :

http://talkchess.com/forum/viewtopic.ph ... 00&t=60990

[Sven]

What we need to understand, though, is why so many WB engines do not appear to have this problem when playing under ChessGUI, or at least why this problem has not been reported so far within many years of using ChessGUI with WB engines and GUI opening book.

As yet, there is no xboard author that says he does not have a timer problem with ChessGUI.

I downloaded ChessGUI but for some unknown reason I can't get it to run on my computer so currently I can't check my own engine Jumbo. But Graham already checked it and wrote that Jumbo would behave normally under ChessGUI. In the same post he also stated the same for a couple of other WB engines.

It would be interesting to see the debug logs of one test game per engine for a variety of WB engines played under ChessGUI against the same opponent, with conventional TC and always given the same opening position. To keep the logs small the TC could be 12/1 (12 moves in 1 minute repeating), with a simple and balanced opening position after the 6th move of black (full move number in FEN = 7). Then we could see which engines use about 5 seconds per move for their first 6 moves, then get another 60 seconds added by the GUI (sent via "time"), and now use about 15 seconds per move for their next 6 moves since they think they are still in first time control. In theory that should be virtually *all* engines. But if there are exceptions then we would need to analyze these.