Time usage of winboard engines

[Sven Schüle]

I see no benefit in pretending to a user that the programs he wants to play chess with have capabilities that in reality they haven't. You "cheat" the user by doing that. It is more than annoying for me to see dubious and surprising behaviour of my software at some point in time, instead of just being told that what I want to do is not possible with *this* software (i.e., engine) for *that* reason. Much better though would be not even to offer multi-session time control to the user unless all opponents have declared to support this non-standard feature. (Of course this would cover graphical interaction only.)

It is very hard to convince you of anything, Harm ...

Sven

[Sven Schüle]

I see no benefit in using a different keyword for the same command, depending on the number of arguments it has.

The benefit would be that engines wanting to support the new functionality only have to *add* new code for a new command while leaving their "level" implementation untouched. Many "level" implementations will (unfortunately - but that's another issue) be based on some sscanf() code which would be no longer appropriate for a variable number of parameters. So in order to keep the existing functionality safe I would prefer not to be forced to change my working "level" implementation only to support multi-session TC.

Sven

[Miguel A. Ballicora]

I therefore support the proposal to define that "feature mlevel=1" (default 0) means the engine understands a new "mlevel" command that takes a multiple of three arguments, so that WB would use "mlevel" instead of "level" whenever a multi-session time control is requested by the user.

Now this is exactly what I don't want: Needlessly add a new command, and complicate the GUI because the kludge is different from the regular way with engines that implement the feature.

Whether a new command is needed or not may be a matter of taste. But the feature "multi-session time control" is a new feature which does not yet exist officially for current engines, so there are indeed both choices: either create a new command or change an existing command. Engines supporting the new feature would have no problem in both cases, they need new code anyway to recognize the new syntax and to implement the new time control behaviour. Engines not supporting it shall never receive a command from the GUI that they cannot handle [EDIT: ok, they can of course ignore it], so in case you define a new command the GUI should never send it to them, while in case you don't, the GUI should never send the old command with new syntax to them. That's simple to understand, I hope.

I don't understand your comment about complicating the GUI since the GUI will definitely have to detect whether the user has specified multi-session TC or not, except if you want to rewrite the time control part of WB completely.

In my logic the new semantics of level is 100% upward compatible with that of the old level command. level 40 5 0 would mean exactly the same as mlevel 40 5 0. They should thus be the same command. And using mlevel in stead of level would break all existing engines.

It seems you misunderstood my intention, and maybe also that of Miguel. "mlevel 40 5 0" would never be sent since this is not a multi-session time control. I think of the following:

a) WB user specifies "regular" time control (no multi-session)
=> WB always uses "level <MPS> <TC> <INC>" for all engines

b) WB user specifies multi-session time control

b1) Engine does not accept new feature
=> WB either politely rejects the user request, and uses "level <MPS> <TC> <INC>" once at startup for this engine, or uses some "intelligent" workaround based on sending multiple "level <MPS> <TC> <INC>" commands [although I would really dislike this!] in case it can be *sure* that it does not break that engine

b2) Engine accepts new feature
=> WB uses "mlevel <MPS1> <TC1> <INC1> <MPS2> <TC2> <INC2> ..." for this engine

That is what I meant. Note that in b2, it may be a good idea to receive that same type of "updates" that b1 will be receiving with maybe
==> mlevel update <MPS2> <TC2> <INC2> <MPS3> <TC3> <INC3>

Miguel

As to the naming of the feature, this really seems quite irrelevant to me. I could name it feature klhsgklghl=1, and the only reason not to do so is adopting the philosophy that one should make life easier for programmers by taking short feature names with mnemonic value. And if the command would remain mlevel, I don't think it is a good thing tio name the feature different, even if it is just by prefixing another letter. People would still have to remember which letter it was. And level=1 would mean that the engine fully understands the level command. level=0 would mean that it only partly understands it. So you might argue that this indeed makes it different from setboard=0, etc. But as level=0 is the default, there will be no reason to ever send it, so this difference is quite academic.

I think after my explanation in my previous post, where I listed 10 other command/feature pairs, only a small minority would accept the feature name "level" as more appropriate than "mlevel", independent from the command name.

Sven

[H.G.Muller]

The code for the new level command would either be wrong, or it could handle the old level command correctly, as the old level is just a special case of the new one. The old level command is suspect anyway, as it might not be able to handle level commands during the game. Allowing people to keep their old code will likely cause more bugs than forcing them to think about how to re-write it.

Hypothetically, I could be convinced by good arguments. But so far I did not recognize any. Arguments like "The original WB protocol was clearly designed in the spirit of ..." is really nothing more than a totally unfounded personal opinion. And I tend to discard personal opinions if they happen not to coincide with my own.

The point is that in this case you don't know what capabilities the software has, and I consider making something impossible in a case where it would have worked a greater eval than attempting something that then turns out not to work. Because in the first case there are no work-arounds, while in the second case the work-around is very simple: "don't do it again!".

Your point that interactive play, using the menus, is different from automated play using the options, is well taken, though. Problem is that I absolutely hate greying out menu items; one of my gravest annoyences with WinBoard is that it grays out menu items I want to use. E.g. if there is no engine, the TC menu is grayed out. While I think it is a perfectly valid desire to use that menu in such a case for the purpose of changing the TC setting in the winboard.ini file. Similar for nalimov path etc. What would it hurt if people used the TC menu in game-viewer mode? This is simply pedantic behavior that never does any good an can at best be annoying.

So if we agree that interactive play should be fool proof, I still would not grey out anything just because it might not work correctly. (It is not like the hard-disk would be wiped if the engine does not understand the TC...) But I could pop up a warning. In practice this will probably lead to moronic "Are you sure?" type popups...

But all that has very little to do with the implementation in WB protocol, which we were discussing before. This is well shielded from the user, and engine authors typically are not morons.

[Miguel A. Ballicora]

I see no benefit in using a different keyword for the same command, depending on the number of arguments it has.

What is the benefit of using the same keyword? Is there any? If I understood correctly, you can achieve what you want using a different keyword. The benefit I see with a different keyword is that it will avoid changing the meaning of an established keyword. This may be academic, but I believe is not a good idea to have a keyword that mean different things according the the version of the protocol, whether the engine acknowledges it or not. At least, it will spare the confusion among future developers, who will have to read the protocol ten times to make sure they understood. I won't be surprised if some of them will plainly screw up.

Miguel

The semantics of the multi-session case is such that it implies indefinite repetition of the last-mentioned parameter group, when the number of listsd sessions is not sufficient to cover the entire game. (This can only happen when MPS of the last session is different from zero, e.g. level 40 40 0 20 15 0.) So the general definition of mlevel does define a meaning for an mlevel command with only 3 parameters, which is identical to the meaning of the existing level command. Trying to exclude it, would be purely artificial, and only leads to proliferation of commands. I am just as likely to do that as adding an emit N command that people can use to transmit time N for odd N...

We also seem to have a different philosophy w.r.t. the loyalty obligations of a GUI. If the user has a difference of opinion with the engine, I like the GUI to side with the user, not the engine. So if I, as user, decide to specify a multi-session TC, the engine will get it in one form or another. Perhaps it is tolerable if the GUI would warn me if the engine doesn't like it, although I imagine that would become annoying very quickly.

[H.G.Muller]

The benefit I see with a different keyword is that it will avoid changing the meaning of an established keyword.

But the meaning is the same... level N M I will mean exactly the same thing as it always meant. Yet another argument that is plainly untrue. Are you really surprised that this doesn't convince me?

[Miguel A. Ballicora]

The benefit I see with a different keyword is that it will avoid changing the meaning of an established keyword.

But the meaning is the same... level N M I will mean exactly the same thing as it always meant. Yet another argument that is plainly untrue. Are you really surprised that this doesn't convince me?

level N M I N2 M2 I2
is not the same as the old level, which is what you will send to "new" engines.

In other words, "feature level=1" would mean: "I understand the redefinition of level to a more flexible command".

This is where I have a different view. Rather than redefining a keyword, it would be more understandable and straighforward to come up with a new one.

Miguel

[Sven Schüle]

The code for the new level command would either be wrong, or it could handle the old level command correctly, as the old level is just a special case of the new one.

It *could become* a special case. But it is not necessary to use the new level command for that "special case", it is only needed if the user requests the new time control feature and the involved engines understand it.

The old level command is suspect anyway, as it might not be able to handle level commands during the game.

This has not been a requirement at the time of its creation (nor am I really sure that it is today), so why do you call it "suspect"? It has been specified and implemented according to the requirements that were valid at that time.

Allowing people to keep their old code will likely cause more bugs than forcing them to think about how to re-write it.

A very questionable approach. That "old code" handles the "old" level command, and in general there will be nothing wrong with it, except for the minor problem that you dislike the "old" level command. Adding new code to handle the "new" level command (here: "mlevel") would not affect the "old" level implementation at all, so why should this cause more bugs?

I am immediately with you when we are talking about usefulness of "refactoring" in software development. Yes, it *is* useful in many cases, under certain circumstances, and I practice it frequently myself. But we have a different case here: it is not *one* software project controlled by *one* central instance or a group of developers, but *some hundreds* of engine developers have working engines on the "market", and we are thinking about adding a new feature to a common interface that they are all using. So why should we be so arrogant forcing all of them to change their working code if they want to support that feature?

Also talking about these concepts will be simplified considerably by using two different command names "level" and "mlevel" instead of having to say "old level command" and "new level command". The "old" one will persist forever since you *must* continue to support engines that do not implement the new feature, including those that will not be changed anymore for arbitrary reasons. So you could not argue that it were only a matter of time until everyone uses the "new" command.

Besides, it is important to have a simple, unambiguous wording that everyone is able to understand quickly, and that is only the case when having two different names.

Hypothetically, I could be convinced by good arguments. But so far I did not recognize any. Arguments like "The original WB protocol was clearly designed in the spirit of ..." is really nothing more than a totally unfounded personal opinion.

It is a proven fact, not a personal opinion, that up to now (or - to be safe - let's say, in the "classical" line) WB sends "level" only once at startup of a game. From this you can definitely derive the "spirit" of the original WB protocol. If the intention had been to also send intra-game level commands, then why has this never been done?

As to your "not recognizing any good arguments". For several days I'm trying to convince you now. Do you intend to say that nothing of what I wrote was a "good argument" for you?

And I tend to discard personal opinions if they happen not to coincide with my own.

... which explains quite a lot

Sven

[Sven Schüle]

The benefit I see with a different keyword is that it will avoid changing the meaning of an established keyword.

But the meaning is the same... level N M I will mean exactly the same thing as it always meant. Yet another argument that is plainly untrue. Are you really surprised that this doesn't convince me?

level N M I N2 M2 I2
is not the same as the old level, which is what you will send to "new" engines.

In other words, "feature level=1" would mean: "I understand the redefinition of level to a more flexible command".

This is where I have a different view. Rather than redefining a keyword, it would be more understandable and straighforward to come up with a new one.

Miguel

It is no surprise that I fully agree to this.
Sven

[H.G.Muller]

Indeed, we do have a different terminology as well as a different philosophy here.

Expanding a definition is not the same as redefining something. Expanding a definition, i.e. assigning a meaning to cases where originally the concept was undefined, is OK, and in fact highly recommended if the meaning in the new case is a logical and obvious exttrapolation of that of the old case. Redefining, i.e. assigning another meaning to a case where the concept originally was defined, is not; it is a deadly sin.

Due to generalization of the level command, new engines will only have to program a single command. Old engines that program the new command, which they would have to do anyway, can drop the old one as it becomes unreachable code when the generalized code catches also the old case. No one is off any better anytime when different keywords were used. In all cases where it does make a difference, using different keywords is more work. That makes it a highly inferior way of designing the protocol.

[Miguel A. Ballicora]

Indeed, we do have a different terminology as well as a different philosophy here.

Expanding a definition is not the same as redefining something. Expanding a definition, i.e. assigning a meaning to cases where originally the concept was undefined, is OK, and in fact highly recommended if the meaning in the new case is a logical and obvious exttrapolation of that of the old case. Redefining, i.e. assigning another meaning to a case where the concept originally was defined, is not; it is a deadly sin.

What you call "undefined behavior" is your interpretation of a loophole in the wording of the protocol. I agree, it never says "Winboard will never send another level during the game", but the whole text talks like the intention is to be operated at the beginning of the game. There are strong hints about it (see below some excerpts). If the intention of level was to play several unmodified sessions during the whole game (my interpretation of what the protocol meant), then, you are changing the meaning of level with "feature level=1", IMHO.

"In conventional clock mode, every time control period is the same...
[some text here]
...The command to set a conventional time control looks like this:
level 40 5 0
level 40 0:30 0"

"...Here the 0 means "play the whole game in this time control period"

"At the start of the game, each player's clock is set to base minutes...."

Miguel

Due to generalization of the level command, new engines will only have to program a single command. Old engines that program the new command, which they would have to do anyway, can drop the old one as it becomes unreachable code when the generalized code catches also the old case. No one is off any better anytime when different keywords were used. In all cases where it does make a difference, using different keywords is more work. That makes it a highly inferior way of designing the protocol.

[H.G.Muller]

Well, like you say, this is your interpretation. I always interpreted the same wording as that a level command would start an epoch of timed play, that started in the current position. This current position does not need to be the standard opening array of FIDE Chess, but can be a set-up position. It can be set up by means of the 'Edit Position' menu, but it can be set up just as well in 'Edit Game' mode. Note that WinBoard sends the initial position (either implied by a variant command, or as a setboard) before it sends a level command.

If there is an interpretation that would force you to design a poor protocol, while another interpretation would allow you to design a good protocol, I see no logic in adhering to the problematic interpretation. Like in the famous dialog:

Patient: Doctor, when I bend backwards to touch my heels, by back hurts like hell.
Doctor: Well, don't do it, then...

[Michel]

As long as things things are fully backwards compatible I don't care.

But what about more exotic time controls like asymmetric ones (e.g. untimed for the human, timed for the engine), or "equal time" (which some people seem to like)?

It is interesting to note that for UCI engines all this is mostly a non-issue.

[H.G.Muller]

Untimed for the Human is in practie done by playing with -autoCallFlag off. I never heard of 'equal time'. Is this where the engine loses as soon as it has used more time than the Human? I guess that for an engine this is similar to an incremental time control, because Humans need a certain minimal time (like 2 sec) to physically make the moves. So you could set the engine for 0:01+2, and have the GUI send it the time difference with the opponent's time in stead of the difference with a fixed session duration. The engine would never need to know that something fishy is going on.

It can only be no issue for UCI engines when they are not capable to allocate their time at all. As soon as they need to allocate their time, they will have to know be able to make a reasonable estimate of how much time they have upto game end.