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

[bob]

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.

No disagreement there. Giving the engine a customizable set of controls to set values specific to that engine is a good idea. But the rest of the protocol, namely the part that actually handles the chess playing rather than the setup, is really a kludge...

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?

[bob]

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

UCI lacks more than that, and also includes more than it should of other things. Some of it is quite good, such as being able to define custom controls to twiddle with engine parameters, defined dynamically by the engine when it starts up. But the intrusive way it interacts with the engine is not a good thing IMHO. It is trying to _control_ the engine. When it is, in reality, only suppose to serve as an interface between the user and program, or between two programs. Would you play in a human tournament game where the arbiter told you what move to expect from the opponent and you can only think about that move while your opponent is on move. Would you want the arbiter to tell you what to do , when to stop doing it, etc? Not me. That's the part of UCI I object to... It is too intrusive into things best left to the engine...

[bob]

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.

I have never seen the flag-fall rule interpreted in that light. The rule has always been enforced as "does the side that wins when the flag falls have enough material to _FORCE_ checkmate. In your example, the answer is "no", because the opponent has to helpmate himself.

But I've only seen this used in speed-tupe events anyway...

[bob]

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.

HG, I have no idea what your problem is. But whatever the case, I am not talking about "imaginary hypothetical problems". Ask fishbait on ICC just how "imaginary" this problem was when I first started talking to them about it several years ago. It wasn't imaginary then, it wasn't imaginary now. If you can't figure out how the O/S does its context switches between processes to make this happen, then perhaps you need to study that problem, rather than painting with such a broad brush and calling it "imaginary". It is _very_ real...

Isn't it about time to stop this form of discussion, where if you don't understand something you label it as "imaginary" only because you don't see the problem yourself. It is there. Any good student could grasp the idea once the issue of an O/S, and timeslicing between multiple processes is discussed. Or once he has written some TCP/IP software and noticed how odd packet arrivals can be, with respect to time delays...

[Alessandro Scotti]

But the intrusive way it interacts with the engine is not a good thing IMHO. It is trying to _control_ the engine. When it is, in reality, only suppose to serve as an interface between the user and program, or between two programs.

This point is central to all the debate, as Winboard and UCI start from two entirely different concepts and philosophies.
In Winboard, programs are fully independent chess playing entities. In UCI, they are chess "thinking" modules to be used by some external agent.
It's possible to agree or disagree with each philosophy of course, but each protocol should be evaluated within its design framework.
Thus, it is not correct to say that "it is only supposed to serve as an interface between the user and program", IMO. That's the goal for Winboard not UCI, and UCI is really supposed to be a different thing, otherwise we would be better served with Winboard 3.

[hgm]

Well, I have no idea what your problem is. Fact is that WinBoard_F works satisfactory no matter what order the packets come in. Hence I consider your problems imaginary. And as long as you don't actually show me a winboard.debug file that documents the occurrence of a wrong call, the problems are also hypothetical.

[Matthias Gemuh]

UCI lacks more than that, and also includes more than it should of other things. Some of it is quite good, such as being able to define custom controls to twiddle with engine parameters, defined dynamically by the engine when it starts up. But the intrusive way it interacts with the engine is not a good thing IMHO. It is trying to _control_ the engine. When it is, in reality, only suppose to serve as an interface between the user and program, or between two programs. Would you play in a human tournament game where the arbiter told you what move to expect from the opponent and you can only think about that move while your opponent is on move. Would you want the arbiter to tell you what to do , when to stop doing it, etc? Not me. That's the part of UCI I object to... It is too intrusive into things best left to the engine...

Yes, UCI controls the engines while WB sits there pondering what the engines are doing.
The lack of flexible time controls in WB is very annoying.
UCI handles a vast variety of time controls, e.g.

a/b+c
a/b +c/d+e/f+g

[hgm]

Yes, UCI controls the engines while WB sits there pondering what the engines are doing.
The lack of flexible time controls in WB is very annoying.
UCI handles a vast variety of time controls, e.g.

a/b+c
a/b +c/d+e/f+g

This is not a fundamental shortcoming of the WinBoard philosophy. It would be easy enough to add more 'flavors' of time control in the 'level' command. E.g. by allowing an arbitrary odd number of numeric arguments.

level a b c d e f 0 g 0

where a, c, e and 0 would specify number of moves, and b, d, f and g would specify number of minutes for these moves. Once a number of moves is 0 it would mean "rest of the game", and that no more (moves,minutes) pair will follow. The last number would be seconds of increment per move. Then the above would exactly produce your second example. If the last specified moves/minute interval would not have 0 moves, it would be taken repetitively for the rest of the game.

I could implement this for you in a minute, if anyone wants it. The engine could switch it on through the protocol-2 "features" command, by setting xlevel=1. There is no reason to introduce a higher protocol version for this, in protocol 2 GUIs that do not implement it, the feature would simply be rejected. The engine would not even have to test for acceptance or rejecting of the feature, as it does not affect anything the engine does, but something the GUI does. The engine will know it was accepted if it gets a level command with more than 3 arguments, and if it was rejected, it will simply never get that. And the interpretation of level commands with 3 arguments is not changed.

So I could add any time, if there is demand for this.

[Uri Blass]

Yes, UCI controls the engines while WB sits there pondering what the engines are doing.
The lack of flexible time controls in WB is very annoying.
UCI handles a vast variety of time controls, e.g.

a/b+c
a/b +c/d+e/f+g

This is not a fundamental shortcoming of the WinBoard philosophy. It would be easy enough to add more 'flavors' of time control in the 'level' command. E.g. by allowing an arbitrary odd number of numeric arguments.

level a b c d e f 0 g 0

where a, c, e and 0 would specify number of moves, and b, d, f and g would specify number of minutes for these moves. Once a number of moves is 0 it would mean "rest of the game", and that no more (moves,minutes) pair will follow. The last number would be seconds of increment per move. Then the above would exactly produce your second example. If the last specified moves/minute interval would not have 0 moves, it would be taken repetitively for the rest of the game.

I could implement this for you in a minute, if anyone wants it. The engine could switch it on through the protocol-2 "features" command, by setting xlevel=1. There is no reason to introduce a higher protocol version for this, in protocol 2 GUIs that do not implement it, the feature would simply be rejected. The engine would not even have to test for acceptance or rejecting of the feature, as it does not affect anything the engine does, but something the GUI does. The engine will know it was accepted if it gets a level command with more than 3 arguments, and if it was rejected, it will simply never get that. And the interpretation of level commands with 3 arguments is not changed.

So I could add any time, if there is demand for this.

It is better if you are consistent with what is already implemented
for part of the winboard engines

http://groups.yahoo.com/group/chess-engines/message/271

winboard practically should understand
level MPS BASE INC or
level MPS BASE INC MPS2 BASE2 INC2 or
level MPS BASE INC MPS2 BASE2 INC2 MPS3 BASE3 INC3

Mathematically there is an infinite sequence
MPS(i)
BASE(i)
INC(i)

If winboard get m time controls when m>=1 then
Winboard should assume that
MPS(i+1)=MPS(i) for i>=m
BASE(i+1)=BASE(i) for i>=m
INC(i+1)=INC(i) for i>=m

Now you have the following algorithm(I understood it but it took me time to define it mathematically)

1)i=1
2)Add Base(i) minutes to the engines and if MPS(i)==0 then goto 6
3)add INC(i) seconds after every move of the next MPS(i) moves
4)i=i+1
5)goto 2
6)Add INC(i) seconds after every move


Uri

[hgm]

At first glance I think you summarize my algorithm correctly.

But on second thought I think it is better to start adding the increment only in 'intervals' (= parts of the game to which an MPS and BASE apply) that have MPS=0. If you have to play 60 moves in 60 minutes, with an increment of 1 sec/move, you might as well specify 60 moves in 61 minutes, without increment.

So the increment adds no new feature if a number of moves is specified. Note that the current protocol does not even define an effect of the level command if not at least one of the moves or increment is zero. (Internally it forces one of the two to zero in the current implementation.) So it seems useles to specify both MPS(i) and BASE(i). There just has to one INC, for the interval that has MPS(i) = 0.

AFAIK there is no protocol-3 definition. Rather than implementing anything that flies around over the net, I would first have a consensus that has been thought about well enough to eliminate the nonsense. And even more importantly, look what time controls other GUIs do support for other protocols, and make sure that fuctionality is also supported. Otherwise I would prefer implementing my own ideas over just following someone who happened to be first in shouting a silly idea.