It's a plague of Winboard engines

[Michel]

GNU Chess is losing on time about once every 10 games in my tests.

Could you specify what the time controls are? Is an external book used. Does GNUCHess use its internal book as well?

There was indeed a serious bug in the time allocation code of GNUChess but it had the effect of allocating too little time rather than too much. So it would
not cause a time loss.

EDIT: Ok I found another bug that might explain the time loss.

[Kirill Kryukov]

GNU Chess is losing on time about once every 10 games in my tests.

Could you specify what the time controls are? Is an external book used. Does GNUCHess use its internal book as well?

There was indeed a serious bug in the time allocation code of GNUChess but it had the effect of allocating too little time rather than too much. So it would
not cause a time loss.

Time control: 40 moves in 4 minutes, repeated.

Time losses happen both with and without an external book.

GNU Chess own book is disabled (By deleting the "book.dat" file).

I run "gnuchess_x64.exe -s 2097152" command line to set the hash size. (I use Jim Ablett's 64-bit compile of GNU Chess 5.07).

EDIT: Ok I found another bug that might explain the time loss.

Excellent!

[H.G.Muller]

-firstXBook did the job.

using 1 instead of true seems to work.

Yes, I am sorry this requires such a cumbersome combination of options. This was inherited from Wiboard_x, and I guess there is som rationalization for it. The -usePolyglotBook is an option that can be used to globally enable / disable the use of the book, without having to destroy the setting for the filename of the book. It is saved in the winboard.ini file. Once a book is installed, the volatile options -firstXbook, -secondXBook control the use of the book by individual engines, and are supposed to be handed to WinBoard by the tournament manager together with the engine name.

For XBoard, which has no .ini file, having to give so many options is a bit cumbersome.

[Michel]

GNU Chess is losing on time about once every 10 games in my tests.

Could you have a look if the new GNUCHess I posted by any chance fixes this problem (there is a 64 bit compile by Jim).
This is version 5.07.1b.

This version has still issues but I have not found more bugs in the timing code.

[Kirill Kryukov]

GNU Chess is losing on time about once every 10 games in my tests.

Could you have a look if the new GNUCHess I posted by any chance fixes this problem (there is a 64 bit compile by Jim).
This is version 5.07.1b.

This version has still issues but I have not found more bugs in the timing code.

Thanks! I'll try to run it after my current match is finished.

[Don Cross]

For anyone who may be interested, I just fixed a couple more bugs in my WinBoard engine XChenard (now version 2009.12.08):

http://cosinekitty.com/chenard/wxchenard.zip

It turns out that having each engine manage the clock is fairly error-prone. I am not proud of saying this, because it seems silly, but there is empirical evidence that many WinBoard/xboard engine authors get it wrong, and wrong in multiple ways. I would like to propose a feature command for a future revision of the protocol. The engine should be able to issue a feature request something like

feature movecounts=1

(Or whatever name makes sense.) Of course, if an older WinBoard/xboard does not understand this feature request, it will reject it, and the engine can either decide to pout and die, or it can muddle along the best it can with the existing protocol. Otherwise, WinBoard will accept the request and subsequently send all "time" and "otim" commands in this format:

time <centiseconds> <remaining_moves_in_period>
otim <centiseconds> <remaining_moves_in_period>

WinBoard already knows these values because it has to track them for knowing when one period has ended and another one begun, so why not ease the burden on future chess engine authors so they can get this right the first time?

[Kirill Kryukov]

Isn't it easier to just implement UCI in an engine? With stateless UCI move-counting and time tracking will immediately work correctly in every existing GUI, and Polyglot can be used for interfacing with Winboard. (Or both protocols can be implemented).

Well, the main issue is with the old engines anyway. As long as the author is still active, the problem can be reported and fixed. But the old engines are those left without a fix or a workaround.

[Don Cross]

Hi Kirill,

Those are valid points. I am considering supporting UCI in addition to WinBoard/xboard. I know this idea wouldn't help legacy WinBoard/xboard engines. However, I still think it would be nice to have this option available for those of us who actively support our WinBoard engines, and especially people new to chess programming who are writing the super-star chess engines of the future!

It seems like an easy thing to implement, and I can't see that it would cause any compatibility issues with older code.

[Kirill Kryukov]

I am all for improving the Winboard protocol, as long as the improvement is 100% bullet-proof backwards compatible. HGM is probably the person to discuss this with, since without GUI support the protocol improvement won't be very useful.

I am considering supporting UCI in addition to WinBoard/xboard.

This would be really terrific!

By the way, here is percentage of buggy engines in my tournament:

Winboard: 16/58 = 27.6%
UCI: 5/44 = 11.4%

(Chess-playing bugs like making bad moves in some positions or even blunders are not counted. Only crashes, losses on time and serious protocol issues.)

[H.G.Muller]

Isn't it easier to just implement UCI in an engine? With stateless UCI move-counting and time tracking will immediately work correctly in every existing GUI, and Polyglot can be used for interfacing with Winboard. (Or both protocols can be implemented).

I don't think UCI has any advantage whatsoever. If you don't correctly count the moves, (i.e. subtract moves that should not have been counted from the nr of moves still to go to the end of the session, or fail to subtract moves that should have been counted), neither UCI nor WinBoard engines will allocate their time sensibly. There is always an opportunity to do it wrong.

That so many WinBoard engines suffer from this, is not because there is a problem with WB protocol, but because there is an influential example engine (GNU Chess) that happens to have this bug, and many people copied it. If Fruit would have had a buggy implementation of UCI, it would have been the UCI engines that had the highest problem rate.

Note that WB protocol can also be used in a stateless way, by sending new + force + level + a list of moves + go on every move. In fact some commercial interfaces (e.g. ChessBase, Shredder) seem to work this way. Of course the buggy WB engines behave even more buggy (even without external book) when you run them this way, as you force in moves, and they still do not count those...

Implement the protocol (which for WB protocol is trivial), and you will have no problems. Implement something different, and it will not work. This is true for any protocol, stateless or not.

[Don Cross]

That so many WinBoard engines suffer from this, is not because there is a problem with WB protocol, but because there is an influential example engine (GNU Chess) that happens to have this bug, and many people copied it.
...
Implement the protocol (which for WB protocol is trivial), and you will have no problems. Implement something different, and it will not work. This is true for any protocol, stateless or not.

I guess I must be very original, because I managed to make these mistakes without copying anybody! I have never looked at GNU Chess source code, nor the source code for any other WinBoard engine; I just took my existing chess engine and did the best I could reading the protocol specification to make a WinBoard version. I think I have it all figured out now, but I would not be surprised to receive another email telling me my program lost on time again because it got confused about how many moves remained in the current time period due to yet another special case I didn't foresee. I sincerely think having the option (disabled by default for backward compatibility) to simply put an extra line of C code like if(movesleft_enabled) {printf("movesleft %d\n",...);} in WinBoard would make it a lot easier to make a foolproof time allocation algorithm. WinBoard already knows the answer, so it should be simple to just print it out.

[Michel]

That so many WinBoard engines suffer from this, is not because there is a problem with WB protocol, but because there is an influential example engine (GNU Chess) , and many people copied it.

I very much doubt that. Time allocation is GnuChess is a rather hard to understand mess. I would be extremely surprised if anyone copied from that. Much easier to do it yourself (and then make the same mistakes again).

The reason that old winboard engines suffer from this bug is that in the past it was not common for winboard engines to rely on a gui book, So that part of the time allocation code was simply not tested (or deemed irrelevant).

[H.G.Muller]

I just took my existing chess engine and did the best I could reading the protocol specification to make a WinBoard version.

Wel, it must be he specs that suck then. But that means it is best repaired there.

I don't see there is anything intrnsically difficult here: Move count is a well-defined part of the game state, just like the board position, side to move or 50-move counter. When you do a move, the ply count increments by one. White gets new time in N moves per session after ply 2*N-1, black after 2*N (i.e. when they have done their own N ply), when you start the ply count at 0 (for white-to-move) or 1 (for black-to-move positions).

The start at ply 0 / 1 is what the FEN specifies in a setboard command: currently this will always specify move number 1, implying ply 0 (wtm) or 1 (btm), no matter what move number the FEN you pasted into WinBoard contained. For engines setting up positions through the edit command, the 0 or 1 are implied (just like castling rghts are implied). Plus that you still will be left with the problem what to do when the featre is rejected...

I don't think counting plies is so difficult that there is a need to have the GUI do it for he engine. The modification to an existing engine needed to make it send the feature, check if the GUI accepts it, and parse the extra parameter in the time command, is far greater than simply declaring a parameter int plyCount;, doing plyCount = 0; on new, plyCount = (sideToMove == BLACK); on edit / setboard, and writing movesDone = plyCount/2; when receiving a time command, rather than trying to read it from the time command.

[F.Huber]

Hi Harm,

not related to this thread but I'm just wondering:
almost 2 weeks ago I've read in r.g.c.c. about a new WinBoard release 4.4.2, but don't see any announcement here about a Windows version of it.
Have you stopped working on it?
I don't hope so ...

[Guenther Simon]

Hi Harm,

not related to this thread but I'm just wondering:
almost 2 weeks ago I've read in r.g.c.c. about a new WinBoard release 4.4.2, but don't see any announcement here about a Windows version of it.
Have you stopped working on it?
I don't hope so ...

Hi Franz,

If you look at the Programmers section in CCC you'll find that his latest beta release is just
three days old. Merry Christmas.

Guenther

[F.Huber]

Thanks Guenther, a good tip!

Best wishes also to you,
Franz.

[H.G.Muller]

Have you stopped working on it?

Don't worry, I spent the past two weeks on Gran Canaria and returned only early this morning. And I did not have good internet access there, and was not carrying my develpment computer. So I did not have software with me to create a new installer.

I will create an installer with the 4.4.2 exe shortly. It was only a bug-fix version anyway, although one of the bugs was bad. (Castling rights messed up after FEN pasting.) There will be no new features in the 4.4.x series. The really interesting series in the future will be the 'development version', the latest descedant of which is in the winboard.zip on my website. This one allows you to walk the PV of an engine, has variation support, better multi-variation mode. (And for XBoard an eval-graph window, a settings file and a real file-selectr dialog.) We hope to make an official release of that one soon, but now Arun is on holiday.

[F.Huber]

I spent the past two weeks on Gran Canaria

Wow, "der Neid koennte einen fressen"!
(sorry, can't translate this into English)
I hope the shock coming back to our continental 'refrigerator' was not too big.

But good to hear that you've not completely retired from WB development ...

Regards,
Franz

[Don Cross]

I just took my existing chess engine and did the best I could reading the protocol specification to make a WinBoard version.

Wel, it must be he specs that suck then. But that means it is best repaired there.

Hi H.G..., I really didn't mean to say anything sucked (other than my own understanding of the protocol). But yes, it would be helpful to list the special cases like you did here in the protocol specification itself.

It is true that this hypothetical feature request from the engine would be rejected by all previous versions of WinBoard/xboard, and then the engine would be back in the same situation. Future chess engine authors would be left with the choice to write either more complicated code for backward compatibility and still risk being buggy on older clients, or to have simple fool-proof code that refuses to run on older clients. Without a time machine, there is no elegant way around this problem.

plyCount = (sideToMove == BLACK); on edit / setboard

Wow, there's another one I missed. Currently I am setting plyCount=0 when "setboard" is received, regardless of whether White or Black has the move. In re-reading section 11 (Time Control), it is not clear how a programmer would know for sure how many moves are left in the time period after "setboard" is received. It also looks like I am not handling the "level" command correctly when it is received in the middle of an ongoing game, since it looks like the period is supposed to be reset to start at the current ply, even though the ply counter has an arbitrary value. This seems to conflict with what you were saying above, or (probably) I simply am not following.

I may end up implementing my feature request in my own copy of the xboard 4.4.2 source code, just so I can have my code compare what it thinks the remaining move count is with what xboard says and throw a hissy-fit if there is any disagreement. (This would purely be for my own testing, and would have no effect on end users because my code will notice the feature is rejected.) If I can figure out how to do this with 2 or 3 lines of extra code, I will post back here in case others want to experiment with it.

[Chris Tatham]

[OT] Harm, now you're back and it's Christmas time, where is your festive avatar!? - a merry Christmas to you and all members!