It's a plague of Winboard engines

[Kirill Kryukov]

Jim Ablett made several GNUchess compilations.
He might be able to fix it.

May be it is more difficult to fix than it seems. Jim tried to fix EXchess about a month ago, but did not succeed yet.

I think I did all I can for GNU Chess. A bug report is posted, the discussion is open, the source code is available. If the bug can't be fixed - well, bad luck for GNU Chess.

[H.G.Muller]

I have checked it again, and indeed it seems that moves played in force mode are simply not counted. GNU Chess 5 gives a non-compliant line of ooutput before every search in which it prints how much time it still has, and how many moves it thinks it has to do in that time. Apparently this is a counter that is different from the one printed in front of the move number. The latter was reset with the "white" command, and the work-around I gave makes this counter behave as it should. But unfortunately this is not the counter that is used for time control.

I let GNU Chess play 2 moves as black, then switch to Edit Game, force in two black moves, and then let it play black again. On the search for the 5th black move it then says it still has 38 moves to go. It just doesn't count the forced moves.

[Don Cross]

Sorry to join the party so late, but I just received a bug report of this exact problem with my chess engine (Chenard). So if I am understanding this right, the bug in my case is that Chenard decrements a counter of how many moves remain in the current time period, and it does so right when it is sending back a move it has just made. Someone is trying to use Chenard in Arena, and Arena uses external opening books by going into "force" mode and making all the moves, then telling Chenard to go when ready. So Chenard thinks it still has 40 moves left in the time period even though it has fewer than that. It sounds like I need to completely rework this by either counting total plies as moves come in, or have a move counter for both Black and White.

[Gábor Szots]

So the list of engines bugged with this same problem (known to me) becomes:

GNU Chess 5.07 (open source)
Resp 0.19 (open source)
Exchess 5.02 beta (open source)
Bodo 0.2b (closed source)
Betsy 6.51 (closed source)

You can add the new Merlin, v2.3.1, as well.

Cheers,

[Don Cross]

...
You can add the new Merlin, v2.3.1, as well.

Oh hi, Gabor! Everyone else, Gabor was the "someone" who reported the bug in Chenard...

[Gábor Szots]

...
You can add the new Merlin, v2.3.1, as well.

Oh hi, Gabor! Everyone else, Gabor was the "someone" who reported the bug in Chenard...

Hi Don,

And now I confirm that the problem is not Arena specific, Chenard behaves similarly under WinBoard and ChessGUI as well.

Maybe there is an open source engine from which the proper method of move counting can be borrowed without violating some copyright. I think the weight of the issue is not great anyway, so giving credit to the original author will do.

[H.G.Muller]

Well, it is no big deal to fix it, once you are aware of the problem. Just count ply in stead of moves, and don´t forget to count on moves that are entered. I don´t think any programmer would need help to fix that on his own engine, once aware that engines are not only meant to play games from the opening position to the end for the same side.

And indeed, this problem is not specific to any GUI. It is simply an incorrect implementation of the protocol, and would occur always when the protocol is used to make the engine play in a game where it does not make all the moves itself.

[Don Cross]

I agree... now that I understand the problem better, the ply-counting method should be easy. I will work on fixing Chenard today and post here when I have a new version available on my web site. Thanks, guys!

[Don Cross]

I have posted a fix for this timing bug in Chenard: it is version 2009.09.19. Please use the link below in my signature line, download the latest wxchenard.zip and replace your copy of xchenard.exe with the contents of that zip file.

It was a fairly simple fix, but for the sake of other authors of WinBoard-compatible chess engines, I think it might be helpful to offer some insight into what I had to do, because there was one slightly tricky bit. WinBoard will send you a "time" command to inform you of how much time you have left, before it sends you the opponent's move (or before the "go" command on the first move). This means it is not your engine's turn (yet). However, if your engine supports pondering, and it is in the middle of pondering when the opponent's move arrives, and that move is not what you expected (pondering miss), you will probably want to call the same time budgeting function after receiving the opponent's move, not after receiving the preceding "time" command. At least this is what I did.

This leads to a special case: in the first case, it is not yet your engine's turn, but in the second case it is. I had to detect whether it was XChenard's turn or not. If not, I pretend like it is by using plycount+1, otherwise I use plycount. Here a code snippet that is executed only when TotalMovesPerPeriod > 0:

Code: Select all

const bool computersTurn = IsComputersTurn();
const int plyCounter = MoveUndoIndex + (computersTurn ? 0 : 1);
const int plyWithinPeriod = plyCounter % (2 * TotalMovesPerPeriod);
const int myRemainingMoves = TotalMovesPerPeriod - (plyWithinPeriod/2);


(You can download the complete C++ source code from my site if you are curious, and find this in xchenard.cpp in the function TimeBudgetForNextMove.)

I tried to test all the special cases (XChenard playing White and Black, pondering and no pondering, pondering miss and pondering hit). I believe it is all working correctly, but hopefully Gabor can re-test with Arena and external opening books and let us know!

[Gábor Szots]

hopefully Gabor can re-test with Arena and external opening books and let us know!

I did a quick test with a couple of engines and everything went well. No pondering was used, though.

Cheers,

[Kirill Kryukov]

So the list of engines bugged with this same problem (known to me) becomes:

GNU Chess 5.07 (open source)
Resp 0.19 (open source)
Exchess 5.02 beta (open source)
Bodo 0.2b (closed source)
Betsy 6.51 (closed source)

You can add the new Merlin, v2.3.1, as well.

Cheers,

Thanks. Does the author know about it? 2.3.1 was released very recently, so may be there is hope the bug can be fixed? (I did not have time to test Merlin 2.3.1 yet).

[Michel]

GNU Chess 5.07 (open source)

Ok I'll fix gnuchess. gnuchess has quite a few cosmetical issues. So it is probably best to fix them all in one go so that gnuchess becomes a fully compliant WB engine. It'll take a bit of time.

[Gábor Szots]

So the list of engines bugged with this same problem (known to me) becomes:

GNU Chess 5.07 (open source)
Resp 0.19 (open source)
Exchess 5.02 beta (open source)
Bodo 0.2b (closed source)
Betsy 6.51 (closed source)

You can add the new Merlin, v2.3.1, as well.

Cheers,

Thanks. Does the author know about it? 2.3.1 was released very recently, so may be there is hope the bug can be fixed? (I did not have time to test Merlin 2.3.1 yet).

I have reported it to him in respect to version 2.0 but he did not have time to fix it. Then it was probably forgotten. I'm going to send him the link to this thread.

EDIT: Report sent.

[Michel]

I fixed already most of the gnuchess issues I think (this needs only a few minor changes).

To check that the timing code is now correct I was trying to use xboard with a GUI book but I can't make it to work.

I used the following command line

xboard -debug -fcp ./gnuchess -scp crafty -usePolyglotBook 1 -polyglotBook performance.bin -size small -mg 1

with performance.bin in the current directory. No book moves seem to be played.

The xboard.debug file shows the line

book hit = (NULL)

in the opening position.

[Gábor Szots]

EDIT: Report sent.

Balázs wrote he's going to study the problem and notify me when a fix is ready. I feel it will take some time.

[Kirill Kryukov]

GNU Chess 5.07 (open source)

Ok I'll fix gnuchess. gnuchess has quite a few cosmetical issues. So it is probably best to fix them all in one go so that gnuchess becomes a fully compliant WB engine. It'll take a bit of time.

Thanks! That would be terrific!

GNU Chess is losing on time about once every 10 games in my tests. This is a big non-cosmetic issue in my book. Do you think you could also look into it? I am testing in 40/4 blitz time control. It happens both with and without external book. I'll be happy to help with testing.

[Kirill Kryukov]

I fixed already most of the gnuchess issues I think (this needs only a few minor changes).

To check that the timing code is now correct I was trying to use xboard with a GUI book but I can't make it to work.

I used the following command line

xboard -debug -fcp ./gnuchess -scp crafty -usePolyglotBook 1 -polyglotBook performance.bin -size small -mg 1

with performance.bin in the current directory. No book moves seem to be played.

The xboard.debug file shows the line

book hit = (NULL)

in the opening position.

Sorry I can't help with this as I don't use WInboard. I run GNU Chess through WB2UCI adapter under Chessbase GUI. However I can test your fixed version if you like.

[Kirill Kryukov]

EDIT: Report sent.

Balázs wrote he's going to study the problem and notify me when a fix is ready. I feel it will take some time.

Thanks Gabor, and thanks to Balazs for looking into it.

[H.G.Muller]

xboard -debug -fcp ./gnuchess -scp crafty -usePolyglotBook 1 -polyglotBook performance.bin -size small -mg 1

You have to add -firstXBook as well (which is shorthand for -firstHasOwnBookUCI false or -fNoOwnBookUCI). Are you sure xboard understands -usePolyglotBook 1 as opposed to -usePolyglotBook true? (This is handled by the X-toolkit option parser routine, so I can't see it in the code.)

[Michel]

-firstXBook did the job.

using 1 instead of true seems to work.