Engine authors, beware of false-draw-claim forfeits!

Discussion of chess software programming and technical issues.

Moderator: Ras

bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Engine authors, beware of false-draw-claim forfeits!

Post by bob »

pedrox wrote:The GUI should not automatically without proof submit the command result and stop the game when he receives a command result of one of the engines. This is a failure of the GUI and I think we should all agree.

DanaSah ignores the command result sent by the GUI, therefore continue the game if she think this is not complete, but with this I am not safe because the GUI may send also a command new.

If DanaSah think that there is a game finish with mate, stalmate or draw by repetition, insufficient material or rule 50 moves then sends the result to the GUI and stop the engine. As I stop the engine I assume if the result is not correct I miss the game. The ideal here is that the GUI could reset the 2 engines, sent by the command edit or setboard the earlier position that it was correct and that the game continued with a penalty of time for the engine that had made the incorrect claim. (On one occasion I claimed draw in a tournament time active 30 minutes finish, the arbitrer said you no reason and I had 2-minute penalty).

If there is a problem in claim draw after sending a move to GUI because the GUI gives the turn to another engine, then why not extend the protocol to version 3?, Protover 3, that version would be consistent with the earlier, and would include the command stop_clock. The protocol xboard was prepared to take further improvements.

This would not affect any engines made to date, they continue playing with protover 1 or 2 and ensure the new engines with protover 3 a claim correct.
That's the solution I have proposed (version 3 keeping 1 and 2 intact for backward compatibility. But we can't get thru the discussion to reach an agreement...
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Engine authors, beware of false-draw-claim forfeits!

Post by bob »

Matthias Gemuh wrote:
Alessandro Scotti wrote:Well then let me add why I love UCI! :-)

1. It's stateless (I don't keep state anywhere in Hamsters)
2. It helps authors from entering endless discussions re: how to handle draws :P
3. Pondering is no different than the standard search: no bugs
4. My standards are not so high, so no comment on this! :-)

Re: protocol incompatibility that's very true though certainly not a "fault" in UCI. I think that any program that wishes to support both Winboard and UCI should be designed carefully. I also think that it would be much easier to add Winboard to an UCI engine than the other way around.

In no part of the code Hamsters knows that it's using the UCI protocol by the way, the engine is given an I/O adapter as a parameter to the search:


UCI is the prefered protocol in commercial engines because it is far better than WB. WB may make sense to some programmer but the user is left in darkness because GUI has no idea what engine is doing and so cannot inform user.

Someone complained about "currmove" in UCI as if "force" makes better sense in WB.


Matthias.
I don't follow the "doesn't know what..." comment. The GUI gives the engine a move, the engine gives the GUI a move. winboard allows the engine to provide score, PV, nodes, etc if desired (show thinking). But the GUI is not _supposed_ to know what the engine is doing. The GUI is the interface between the engine and the user or another engine, it simply needs to relay information between the two combatants. It certainly does not need to play opening moves, endgame tablebase moves and such. Suddenly the GUI plays more moves than the engine in some cases... And that's not acceptable...
User avatar
George Tsavdaris
Posts: 1627
Joined: Thu Mar 09, 2006 12:35 pm

Re: Engine authors, beware of false-draw-claim forfeits!

Post by George Tsavdaris »

bob wrote: I do not believe this factors in to FIDE rules at all. The rule is that if you are playing (say) KRR vs KN, and your flag falls before you force the mate with the KRR, you still can not lose since your opponent lacks the material to force a mate.
But rules don't speak about you be able to force a mate, but if _theoretically_ is possible to mate or not. And having a Knight against 2 Rooks is sufficient material to mate.

[d]8/8/8/8/4N3/1K6/8/rk4r1 b - - 0 1
1...Rc1 2.Nd2+ #

So the black side has no right if his flag falls, to claim a draw. I mean claim a draw long before it gets mated with the silly way i showed of course.
After his son's birth they've asked him:
"Is it a boy or girl?"
YES! He replied.....
wgarvin
Posts: 838
Joined: Thu Jul 05, 2007 5:03 pm
Location: British Columbia, Canada

Re: Engine authors, beware of false-draw-claim forfeits!

Post by wgarvin »

I remember looking at UCI at one point and thinking that the spec was crap. Lots of things were not clearly defined. But then again, the Winboard spec has some weaknesses too.

I think the protocol should make it possible (but not necessary) for engines to explain to the GUI what they are doing--PV, tablebase lookups, etc. I guess there are idioms for Winboard engines to do this even where the protocol does not directly support it?

The one part of UCI that I thought was useful and wished for a comparable Winboard feature, was configuring the engine. UCI lets the engine describe the sort of parameters it accepts -- booleans, integers, etc. and then the GUI can present appropriate widgets to the user for them to tinker with.

I kind of wish someone would design a clean replacement protocol for both UCI and Winboard which covers all the bases and doesn't have any loopholes like the ones that make FIDE-compliant draw handling painful with the Winboard protocol. However, adding another protocol that only some fraction of engines use does not seem like a good idea. The best approach is probably to make a version 3 of the Winboard protocol which makes it easier for engine authors to correctly interact with the GUI (e.g. maybe separate "offer draw" and "claim draw" commands would be useful?).

Its unfortunate that existing and future GUIs will have to be backwards-compatible with the old versions of the protocol basically forever. Perhaps at some point it a standard "old-Winboard-versions-to-latest-Winboard-version" adapter program will emerge and the GUIs themselves could drop the legacy support? I know Winboard contains a lot of special cases and hacks to support various engines that use (or misuse) various legacy features of the protocol. It would be nice if neither engine authors nor GUI authors had to worry about these issues, but maybe they are to a certain extend unavoidable?
User avatar
Matthias Gemuh
Posts: 3245
Joined: Thu Mar 09, 2006 9:10 am

Re: Engine authors, beware of false-draw-claim forfeits!

Post by Matthias Gemuh »

bob wrote:
Matthias Gemuh wrote:
UCI is the prefered protocol in commercial engines because it is far better than WB. WB may make sense to some programmer but the user is left in darkness because GUI has no idea what engine is doing and so cannot inform user.

Someone complained about "currmove" in UCI as if "force" makes better sense in WB.


Matthias.
I don't follow the "doesn't know what..." comment. The GUI gives the engine a move, the engine gives the GUI a move. winboard allows the engine to provide score, PV, nodes, etc if desired (show thinking). But the GUI is not _supposed_ to know what the engine is doing. The GUI is the interface between the engine and the user or another engine, it simply needs to relay information between the two combatants. It certainly does not need to play opening moves, endgame tablebase moves and such. Suddenly the GUI plays more moves than the engine in some cases... And that's not acceptable...



If you feel that the GUI is not supposed to know what engine is doing, then you prefer to keep user in semi darkness. Even at long time controls, user is informed only about main search depth, time, score and beginning of PV. Protocol deprives him of current move being search, current search extensions, search speed, table hits, etc.
A feeble attempt to provide these infos in WB/xboard is to append them to PV, where they stay out of sight. Horrible !

UCI lacks only draw/resign to be perfect.


Matthias
My engine was quite strong till I added knowledge to it.
http://www.chess.hylogic.de
Alessandro Scotti

Re: Engine authors, beware of false-draw-claim forfeits!

Post by Alessandro Scotti »

Matthias Gemuh wrote:If you feel that the GUI is not supposed to know what engine is doing, then you prefer to keep user in semi darkness. Even at long time controls, user is informed only about main search depth, time, score and beginning of PV. Protocol deprives him of current move being search, current search extensions, search speed, table hits, etc.
A feeble attempt to provide these infos in WB/xboard is to append them to PV, where they stay out of sight. Horrible !
Yes, Winboard is weak here without a well defined format for PV and even score (absolute or relative?). In most cases you can get the info anyway (see Winboard X screenshot with move list, score diagram, PV's, move being pondered etc. but also note the PV's for Yace and Kiwi are entirely different) but with much greater effort and without ever being sure there's an incompatible engine somewhere...
Dirt
Posts: 2851
Joined: Wed Mar 08, 2006 10:01 pm
Location: Irvine, CA, USA

Question for HGM

Post by Dirt »

hgm wrote:To prevent out-of-order posting, I am not able to further react in this thread until my comments addressing the points made earlier are put back. Sorry about that.
That's insane! Just when you guys were starting to understand each other.

Perhaps you didn't see this, but Dr. Hyatt made the following point:

It is possible that an engine could make a move, immediately followed by a draw offer that would not be valid without the move. Winboard could receive the move, send it to the other engine, get the move in response, and send the move back to the first engine; and then read the draw offer.

(I apologize if this mischaracterizes what was said.)

It looks to me that the GUI would then have no way to determine which move the draw offer was associated with. Is there some reason this couldn't happen?
User avatar
hgm
Posts: 28353
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: Question for HGM

Post by hgm »

Yes, too bad. But it seems the discussion is permanently disrupted.

Not that it matters much, as WinBoard 4.3.13 already works fully upward compatible with 4.2.7 for engines that stick to the protocol. And engines that don't stick to the protocol of course should be really considered extremely lucky if they do not forfeit their games because of this...

So if you experience any problems while running it (you can download the winboard.exe as the file alpha.tst from my website) should be considered an implementation bug. Just send me the debug file in that case.

Talking about imaginary hypothetical problems is just a waste of time.
User avatar
Zach Wegner
Posts: 1922
Joined: Thu Mar 09, 2006 12:51 am
Location: Earth

Re: Engine authors, beware of false-draw-claim forfeits!

Post by Zach Wegner »

Zach Wegner wrote:4. It's ugly. This is to be expected because it's an "English" protocol written by non-native English speakers. It makes me cringe to read "currmove" and "readyok" in my own code.
I forgot one point, related to this. 'Analyze' is misspelled as 'analyse'.
Alessandro Scotti

Re: Engine authors, beware of false-draw-claim forfeits!

Post by Alessandro Scotti »

Zach Wegner wrote:
Zach Wegner wrote:4. It's ugly. This is to be expected because it's an "English" protocol written by non-native English speakers. It makes me cringe to read "currmove" and "readyok" in my own code.
I forgot one point, related to this. 'Analyze' is misspelled as 'analyse'.
Both forms are valid, but analyse (which is the British spelling) came first! ;-)