Losing on time

[Sven]

So these GUIs are broken, and you can apparently configure cutechess-cli so that it becomes broken too, in order to allow your engine to remain broken, rather than fixing it.

Really smart...

Of course when you would ever play that engine in a serious tourney then, such as on an ICS, it would flag it mercilessly, and you would lose every game on time.

Fully agreed here, such an option has a lot of potential to hide problems.

[Sven]

I fully agree on the "madness" and "idiocy" here But section 13 should not be removed completely since you can't prove that the combination of WinBoard/XBoard 4.2.7 and old GNUchess will never be used again anywhere in our world.

But educating people about the peculiarities of GNU Chess or XBoard 4.2.7 is not the task of this document. Do you explain in the README file that accompanies your engine that things might work differently in GNU Chess? If people want to know how XBoard 4.2.7 works then they should look in the documentation that accompanied XBoard 4.2.7. Not in the CECP specs.

You might want to restructure the document into a "spec" part that is valid for all GUIs and a "WinBoard/XBoard" specific part that describes behavior of these specific GUIs and possibly their specific versions. You would still have to resolve some interdependencies between both, though, e.g. the description of "feature colors" refers to the XBoard specific part.

I don't see a reason why the specific behavior of XBoard versions should be described anywhere. The fact that it is CECP compliant should say everything. Perhaps there could be a caveat in the specs that one should not in general assume that the GUI will send you the obvious and minimal set of commands to perform a given task, but might use arbitrarily cumbersome combinations of commands that according to the specs would eventually have the same result.

IMO a GUI should never employ work-arounds for non-compliant engines, but if it does, publishing them is actually the worst thing you can do. Because it sends the wrong signal that people can count on this behavior, and thus implement commands in other ways that their specified meaning, breaking their engine on other GUIs, or other versions of the same GUI.

You are right. So go ahead and change the existing document "engine-intf.html". It contains a couple of things that are actually not needed. I can live with such a change, and probably many others as well. Of course an additional XBoard documentation would not hurt (but that's not the topic here) ...

And wouldn't you agree that extending the FEN spec for those special variants would be much nicer, easier, future-proof, and more consistent with the idea of a modern WB protocol? Why would you put any effort into that old and clumsy "edit" style? A lot of modern testing technology is based on using FENs (e.g. for opening positions), and if those specific variants shall use that you would need to provide FEN support for it anyway at least on GUI level, but then you have a FEN spec, so why shouldn't engines use it as well via "setboard"?

Yes, that would be nice. If it could be done. But I don't agree that the old 'edit' style is intrinsically clumsy. Extensions of the FEN standard could easily become much more clumsy. Pasting positions into the GUI could definitely become a problem, however. DEMN could be a solution, but it isn't very readable to humans.

What is DEMN?

[bob]

So these GUIs are broken, and you can apparently configure cutechess-cli so that it becomes broken too, in order to allow your engine to remain broken, rather than fixing it.

Really smart...

Of course when you would ever play that engine in a serious tourney then, such as on an ICS, it would flag it mercilessly, and you would lose every game on time.

Fully agreed here, such an option has a lot of potential to hide problems.

The best "fix" is to play game/1sec with no inc. Over and over. Occasionally you will lose on time. But it ought to be WAY in the game. Certainly it should last 100 moves if you use 10ms timing accuracy. This is really not that hard to solve correctly so that it works right on ALL GUIs, not just one with an ugly hack that covers up bugs.

[Rebel]

Over my dead body!

Never will I be an accomplish to such deterioration of standards. WinBoard will remain a reliable interface.

Sure HGM, you define your rules, it's your software after all, no problem. However in the end it's the programmer who decides which GUI's he is going to support.

[Rebel]

2. Secondly some engines (like mine for instance) collect and store all kind of statistic stuff which causes overhead falling outside the limits of the time control.

If you do some expensive stuff in the time between terminating the search and actually sending the move to the GUI then your engine may occasionally lose on time. Would it help to send the move immediately and do the expensive stuff afterwards, when it is not your engine's turn (i.e. it is either idle or pondering, where in the latter case pondering could also start a little later)?

That's a good hint indeed.

[Rebel]

The best "fix" is to play game/1sec with no inc. Over and over. Occasionally you will lose on time. But it ought to be WAY in the game. Certainly it should last 100 moves if you use 10ms timing accuracy. This is really not that hard to solve correctly so that it works right on ALL GUIs, not just one with an ugly hack that covers up bugs.

Small correction, not 100 moves but 1000/15=66.66 moves since clock() and/or GetTickCount() operate in steps of 15, not 10.

[Steve Maughan]

Hi Bob,

Do you produce a log file that shows the target search time at the start of the search and the actual time used at the end?

Thanks!

I implemented this simple suggestion in Maverick. As a result I managed to track down a niggling bug which had been bothering me for a while.

If anyone is interested here's a blog post which describes the bug and it's solution, as well as a brief discussion about high resolution timers.

http://www.chessprogramming.net/compute ... sing-time/

Steve

[hgm]

Sure HGM, you define your rules, it's your software after all, no problem. However in the end it's the programmer who decides which GUI's he is going to support.

And it will be the user who decides if he wants to use the buggy engines that such a programmer produces...

And you know what? I don't care a hoot how many people use WinBoard. Because they don't pay me anyway. So there is no reason whatsoever to prostitute myself in order to attract users. If they prefer crap, let them eat crap! Even if I would be the only person left in the world that values gourmet dishes, it is still worth it to cook for myself. I get more satisfaction from that than from serving crap to a million people. It is the product of quality and quantity that matters.

[Adam Hair]

[MODERATION]

Harm and Ed,

Let's please stay on the topic and avoid the remarks directed towards each other.

Thanks.

[Steve Maughan]

It was all "Double Dutch" to me !

Steve

(Sorry - couldn't resist)