Time usage of winboard engines

[Sven Schüle]

It is the other way round. There is no such special handling of intra-game "level" commands, the handling is always the same: the first of three numbers determines the number of moves per session counted from the beginning of the game. WB engines subtract the number of moves already played from that number to get the number of moves left until next time control. So if they always count the number of moves from ply 0 then this means that they do *not* read the first argument of "level" as number of moves counted from the *current position*.

So basically you are saying that some engines might nor reset their move counter on receipt of a level command, but do it on a new command. (They must reset it somewhere...) Well, for such engines there is no fix unless WinBoard would explicitly count how many of the moves were forced into it, as the number of moves they will assume they have to do in the remaining time will depend on their own internal idea of the number of moves they have already done.

Nowhere is stated that after receiving "level", an engine shall reset some move counter. "level" informs an engine about the overall time control conditions of the game that is being played, and this is done once at the beginning of the game, everywhere on the world, even in human-human games (although not always with a "level" statement but it is similar). I would be glad if the WB protocol spec would contain a sentence that explicity states that "level" is sent only once in the beginning, unfortunately it does not. But that is still not enough justification for me to do something that has not been "forbidden" explicitly, if it obviously modifies the original intention of the WB spec.

I am pretty sure that this has always been the only intent of the WB protocol specifiers for "level". As an example, I also checked the source code of three native WB engines: Delfi, Crafty, Romichess to verify that they handle it as I expected.

But these are engines that work correctly. So it is not very relevant how they would react to a command that would only be sent to broken engines.
[...]
But I don't understand the logic behind your objections. They seem to be based on the hilosophy: "because it does not work always, we should not do it". This is contrary of my philosophy: "even if it works only once, it might be worth it". The cases for which it doesn't work can perhaps be fixed in another way.

I consider it a bad idea to create a new option "/chocolate" which tastes well for a few children whose names are explicitly listed somewhere but which, according to the package insert, has toxic effect for everyone else. It would be o.k. for me if using that new option would be neutral to all other engines that are working correctly w.r.t. the move counter problem.

The multi-session topic may be related to what we discuss here but at least your proposal to optionally send intra-game "level" commands to some engines is something different from the multi-session feature which is definitely desired to have, so I would prefer to leave it out of this discussion.

But we can't, as it is identically the same problem: You have to make the engine aware that it has to last on the current time on its clock for a different number of moves than it is currently thinking. Discuss one, and you are discussing the other. Anyway, for the engines you describe the /%sAccumulateTC would result in the desired effect: By sending the sum of all earlier sessions including the immediately following one would reset their internal MPS notion in such a way that they expect the next time quota at the move where it will indeed come.

I don't think that sending multiple level commands is the only way of implementing a multi-session time control feature. Another way would be to stay with the concept of specifying the whole time control once in the beginning, by using a special string format for "level", or even a new command, in case an engine reports to understand that new feature with an appropriate "feature xxx" message. So again, I don't see a close connection of this with the move counter problem.

I think we are at a point where someone out there with testing capacity (I'm afraid I don't have it) should find out roughly how many, and which, WB engines are really affected, so that we know better if we are talking about a huge crowd of "misbehaving" engines that have created some "de facto standard", or a small handful of poor sinners

Perhaps playing a sequence like the following could be a possible quick test in console mode (I hope to bypass any opening book with 1.a4 g5 ...):

new
level 2 1 0
force
easy
a2a4
g7g5
go
<wait for engine move, then enter a legal answer>
<wait again for next engine move>

Correct behaviour would be that the engine takes all (or most) of the available one minute for its second move (the first after the "book move" 1.a4) and then adds another minute for the next two moves.

Presence of a problem would be indicated if the engine thinks up to half a minute twice and only then adds another minute, i.e. it does not count 1.a4 as part of the game.

Sven

[H.G.Muller]

Nowhere is stated that after receiving "level", an engine shall reset some move counter. "level" informs an engine about the overall time control conditions of the game that is being played, and this is done once at the beginning of the game, everywhere on the world, even in human-human games (although not always with a "level" statement but it is similar). I would be glad if the WB protocol spec would contain a sentence that explicity states that "level" is sent only once in the beginning, unfortunately it does not. But that is still not enough justification for me to do something that has not been "forbidden" explicitly, if it obviously modifies the original intention of the WB spec.

This might be obvious to you, but it is not at all to me. Evidenced by how I implemented the level command in micro-Max and Joker. What seemed obvious to me is that a time control session would be defined before it begins, and this implies that all moves done before the reception of level command would not count as moves in the session that this level command defines. I.e. level must reset the move counter.

I consider it a bad idea to create a new option "/chocolate" which tastes well for a few children whose names are explicitly listed somewhere but which, according to the package insert, has toxic effect for everyone else. It would be o.k. for me if using that new option would be neutral to all other engines that are working correctly w.r.t. the move counter problem.

All prescription drugs fit exactly the description example you give. Are you against medicine? This option is only to be administered to sick engines...

I don't think that sending multiple level commands is the only way of implementing a multi-session time control feature. Another way would be to stay with the concept of specifying the whole time control once in the beginning, by using a special string format for "level", or even a new command, in case an engine reports to understand that new feature with an appropriate "feature xxx" message. So again, I don't see a close connection of this with the move counter problem.

Because you miss the main point. I was asking for a way to do it such that it would work in existing engines. What you propose would not work in any existing engine.

Of course engines can be changed such that they would understand the way you propose to do it. They can be changed to do anything. But that would require a far bigger change than resetting the move counter to zero for every level command you receive. So if we requires engines to be changed, why would we require a complex change rather than a minimal change? That makes no sense to me.

I think we are at a point where someone out there with testing capacity (I'm afraid I don't have it) should find out roughly how many, and which, WB engines are really affected, so that we know better if we are talking about a huge crowd of "misbehaving" engines that have created some "de facto standard", or a small handful of poor sinners

Agreed, that would be useful.

Perhaps playing a sequence like the following could be a possible quick test in console mode (I hope to bypass any opening book with 1.a4 g5 ...):

new
level 2 1 0
force
easy
a2a4
g7g5
go
<wait for engine move, then enter a legal answer>
<wait again for next engine move>

Correct behaviour would be that the engine takes all (or most) of the available one minute for its second move (the first after the "book move" 1.a4) and then adds another minute for the next two moves.

Presence of a problem would be indicated if the engine thinks up to half a minute twice and only then adds another minute, i.e. it does not count 1.a4 as part of the game.

Well, it is difficult. What you propose would for instance not work on micro-Max, which takes a safety margin of 7 moves, because its search time can differ wildly from the target time (as it aways finishes an iteration). So target time is calculated as timeRemaining/(movesRemaining+7), and the actual time would be something between 0.6 and 6 times the target time. That makes it practically impossible to see if the number of remaining moves is 1 or 2.

Perhaps a better way is to play it at 20/1, force 1 move into it from a loadGameFile, adjudicate draw after 22 moves, and look in the PGN how long it has been thinking on move 21. It should be obvious if this is nearly a minute or about 1.5 sec. This is reasonably easy to automate, just play the first round of a huge round-robin, and then go through the PGN file searching for "21.".

Of course I am not really interested in fixing this problem, I am interested in a diagnostic test that checks if the level command resets the move counter. So I would want to send them a level 40 1 0 on move 39 just before time 6000, and then check in the PGN if they use the 1 minute nearly all for a single move, instead of for 40.

[Matthias Gemuh]

... I was already planning to send level commands to engines during a game for the purpose of implementing multi-session time controls ...

ChessGUI would immediately follow and Hyatt would curse.


Matthias.

[H.G.Muller]

... and Hyatt would curse.

You mean because he would like the engine to know in advance? I guess this can indeed be important if the user would abuse the multi-seesion TC to trick the engine, e.g. 40/40 for the first session and then 10 sec for the rest of the game. Such a tournament would likely always be won by the engine that keeps the largest safety margin on the last move of the session.

I am considering two mechanisms for multi-session time controls. There is the old proposal for the v3 protocol, to have a level command with more parameters, in groups of 3, which would be sent only to engines that set feature xlevel=1 (or perhaps a number indicating the maximum number of groups, although it is not clear what WB should do if this number was not sufficient. My suggestion for the latter case would be to use the same strategy as with the normal level command: send a multi-session level command at the beginning at each session, which would contain only the info for the sessions yet to come. So even if the engine would only accept parameters for 2 sessions, if you specified a TC with 4, the level command at the beginning of the game would specifies sessions 1 and 2, that at the beginning of session 2 would specify 2 and 3, etc. Such an engine would then still be able to handle arbitrarily many session, but would have a preview only 1 session ahead. In fact there would be no need for WB to know the number of sessions the engine can understand; it could simply send the parameters for all upcoming sessions always, and the engine would decide how many it likes to read of that.

The alternative, which I actually prefer, is to keep the level command with 3 parameters. The TC is a string parameter, as it must be ale to contain things like 0:30. We can make use of that by putting more information in it. This is how WinBoard already handles the user input to specify multi-session time controls now. WinBoard internally handles the time controls with the aid of the string it would use to specify the TC in the PGN tag. E.g. "40/40+30/15+5+1" would mean 40 moves in the first 40-min session, then 30 moves in a 15-min session, the 5 min + 1 sec/move for the remainder of the game. To translate such a string to a level command it would strip off the first MPS parameter, (if any), to send it separately from the string. So it would send before the game:

level 40 40+30/15+5+1 0

At teh beginning of the second session it would send:

level 30 15+5+1 0

At the beginning of the third session

level 0 5 1

This perhaps has less chance to be accepted by existing engines as the v3 extended level command

level 40 40 0 30 15 0 0 5 1

as the mist obvious way to parse a level command is by

sscanf(inputLine, "level %d %d:%d %d", &moves, &min, &sec, &inc);

followed by

sscanf(inputLine, "level %d %d %d", &moves, &min, &inc);

if that did not provide 4 parameters. This code would not be resistent to extra characters appended to the TC string. Extra characters at the end of the level command would not hurt, though.

[Matthias Gemuh]

level 40 40+30/15+5+1 0

At teh beginning of the second session it would send:

level 30 15+5+1 0

At the beginning of the third session

level 0 5 1

This perhaps has less chance to be accepted by existing engines as the v3 extended level command

level 40 40 0 30 15 0 0 5 1

as the mist obvious way to parse a level command is by

sscanf(inputLine, "level %d %d:%d %d", &moves, &min, &sec, &inc);

followed by

sscanf(inputLine, "level %d %d %d", &moves, &min, &inc);

if that did not provide 4 parameters. This code would not be resistent to extra characters appended to the TC string. Extra characters at the end of the level command would not hurt, though.

I am an UCI fanatic and therefore cannot discuss WB time controls.
I only wait to implement what has been decided.

Matthias.

[Sven Schüle]

I appreciate your activities to prepare and implement a multi-session time control feature for WinBoard. But now I have a general question:

How many percent of the existing engines will probably understand that new feature correctly in your opinion *without any engine code change*,

a) with the "level <moves> <multiTcString> <inc>" syntax,

b) with the "level { <moves> <min>[:<sec>] <inc> }+" syntax (where {...}+ shall mean "one or more occurrences of ...")?

By "understand correctly" I mean the following:
- Do not crash.
- Do not reject the "level" command due to "bad parameters".
- Do not evaluate the <multiTcString> to zero (unless it is really zero, of course, which is irrelevant here).
- Behave as expected w.r.t. the specified time control settings.

In case you answer with some values that are clearly lower than 80-90%, I also would like to know again your specific reasons why you think that defining a new "feature xxx" setting to enable multi-session time control (such that "level" only contains the new format if the engine declares to accept it) would not be appropriate.

Sven

[H.G.Muller]

In case you answer with some values that are clearly lower than 80-90%, I also would like to know again your specific reasons why you think that defining a new "feature xxx" setting to enable multi-session time control (such that "level" only contains the new format if the engine declares to accept it) would not be appropriate.

The fraction is not relevant, as the sending of extra parameters will indeed be controlled by a feature level=1 command. With feature level=0 (the default setting) the information on time controls after the upcoming one would never be sent. With level=1 WinBoard could send an indefinite number of TC parameters in a single level command; it would be upto the engine to decide how many of those it wold actually pay attention to.

So there is no chance that any existing engine would ever crash due to this, unless they would already send the feature level=1, which seems unlikely for an undefined, nonexisting feature. It would be unwise if authors modified their engines to send feature level=1, while not first making the understand multi-session level commands.

So authors do not have to worry much about the multi-session level command when their engine would not be able to adapt its behavior based on the info about the later sessions. They could simply have their engines play based on the info the single-session level commands give them.

[Sven Schüle]

Sounds very good so far!

Only the feature name "level" could be improved perhaps, to make its meaning immediately clear ... For instance, with "feature setboard=1" the engine tells WB that it supports the "setboard" command, whereas "feature level=1" would mean something different, although both "setboard" and "level" are also command names. So what about "multisession", "multisessiontc", "multilevel", "multitc", or something like that?

Now returning to the original problem of this thread (some engines not updating their move counter in "force" mode, resulting in time control problems when using an external book), what is your current view about the best solution? Has there been any testing in the meantime to find out how many engines are affected?

Sven

[Miguel A. Ballicora]

I appreciate your activities to prepare and implement a multi-session time control feature for WinBoard. But now I have a general question:

How many percent of the existing engines will probably understand that new feature correctly in your opinion *without any engine code change*,

a) with the "level <moves> <multiTcString> <inc>" syntax,

b) with the "level { <moves> <min>[:<sec>] <inc> }+" syntax (where {...}+ shall mean "one or more occurrences of ...")?

By "understand correctly" I mean the following:
- Do not crash.
- Do not reject the "level" command due to "bad parameters".
- Do not evaluate the <multiTcString> to zero (unless it is really zero, of course, which is irrelevant here).
- Behave as expected w.r.t. the specified time control settings.

In case you answer with some values that are clearly lower than 80-90%, I also would like to know again your specific reasons why you think that defining a new "feature xxx" setting to enable multi-session time control (such that "level" only contains the new format if the engine declares to accept it) would not be appropriate.

Sven

I think that Gaviota will not behave according to what HGM expects. Gaviota after receiving "level", understand that the number of moves in the command correspond to the number of moves from the "beginning of the game", not from "that point on". That is how I understood the protocol. It is not explicit that the number of moves is from the start of the game, but you can smell that was the spiri. For instance it says: "At the start of the game, each player's clock is set to base minutes...". Was I wrong with that interpretation? maybe. An english scholar may correct me , but I doubt I am alone. The protocol is explicit that with this command level, each session is the same. It says "In conventional clock mode, every time control period is the same" and the conventional clock mode is the one set by level. Then, the engine cannot be expected to receive different level commands to change different sessions. At best, IMHO, this is some sort of undefined behavior and I think it violates the spirit of the command level.

For that reason, I think that we should go for a new command altogether: "mlevel" or so, or redefine it with feature, etc. and the old engines that cannot play multiple different sessions should not be used in matches with this feature. They were not designed for that purpose.
I believe it is better if winboard says "sorry, engine X does not recognize multilevel, choose another setup", rather than forcing them play in suboptimal conditions, just plain broken, or at best, a situation that the author did not anticipate.

Otherwise, some wil behave as HGM, some not. It will be up to the testers to find out which ones and it could be a frustrating experience. How many will break as the latest released Gaviota? we have no idea.

Miguel

[H.G.Muller]

I think that Gaviota will not behave according to what HGM expects. Gaviota after receiving "level", understand that the number of moves in the command correspond to the number of moves from the "beginning of the game", not from "that point on".

This is one of the two behaviors I foresaw. As long as Gaviota does count the moves from the beginning of the game correctly (i.e. also counting forced moves for the color it is playing), this presents no problem. It means Gaviota would have to be run in a muti-session TC game with the option /...AccumulateTC=true. At the beginning of the second TC it would then receive a level command that specifies the sum of the number of moves and session durations of the first 2 sessions as MPS and TC parameters. This would likely simply overwrite the MPS parameter Gaviota was memorizing, so it now does expect the next time control at the correct move. (It would be thinking it was still in the first session of this new TC, but who cares.)

That is how I understood the protocol. It is not explicit that the number of moves is from the start of the game, but you can smell that was the spiri. For instance it says: "At the start of the game, each player's clock is set to base minutes...". Was I wrong with that interpretation? maybe. An english scholar may correct me , but I doubt I am alone. The protocol is explicit that with this command level, each session is the same. It says "In conventional clock mode, every time control period is the same" and the conventional clock mode is the one set by level. Then, the engine cannot be expected to receive different level commands to change different sessions.

That does not necessarily follow. The user could change his mind about which TC he wanted to play. He can change is mind about pretty much everything else, like the time left on the clock, for example (with a time command). He can even change his mind about which side the computer plays! So why not about the TC?

At best, IMHO, this is some sort of undefined behavior and I think it violates the spirit of the command level.

Well, if the "undefined behavior" happens to be the desired behavior, it is "mission accomplished".

For that reason, I think that we should go for a new command altogether: "mlevel" or so, or redefine it with feature, etc. and the old engines that cannot play multiple different sessions should not be used in matches with this feature.

This is for tournament directors to decide. I see no reason to decide it for them by withholding this kludge to do it. I want to have the option to do this, to test my own engine under conditions where it can search deep in the middle-game, and I can speed it up in the end-game. And I want to have a wide choice of opponents to play against. I don't want to have to wait untill one or two people decide to implement this feature.

In any case I would see no reason to use a different level command; what you want would be more easily acheived by making level=0 the defaut for the feature. For engines that exlicitly use the feature it hould be no problem to interpret intra-game level commands as I intend them, and other engines would never have to do it.

They were not designed for that purpose.
I believe it is better if winboard says "sorry, engine X does not recognize multilevel, choose another setup", rather than forcing them play in suboptimal conditions, just plain broken, or at best, a situation that the author did not anticipate.

Here we obviously have a different philosophy. I am a "Yes we can" man...

Otherwise, some wil behave as HGM, some not. It will be up to the testers to find out which ones and it could be a frustrating experience. How many will break as the latest released Gaviota?

Now you are aware of the problem, it would be easy enough to fix it. If testers think it is too frustrating to figure out which engines need the kludge /...AccumulateTC=true, and which engines cannot handle reasonable multi-session TCs at all, they simply should not run this kind of tournament. we laready discussed easy ways to figure out which engines work which way, and perhaps I would publish a list of engines that would work.

[Miguel A. Ballicora]

I think that Gaviota will not behave according to what HGM expects. Gaviota after receiving "level", understand that the number of moves in the command correspond to the number of moves from the "beginning of the game", not from "that point on".

This is one of the two behaviors I foresaw. As long as Gaviota does count the moves from the beginning of the game correctly (i.e. also counting forced moves for the color it is playing), this presents no problem. It means Gaviota would have to be run in a muti-session TC game with the option /...AccumulateTC=true. At the beginning of the second TC it would then receive a level command that specifies the sum of the number of moves and session durations of the first 2 sessions as MPS and TC parameters. This would likely simply overwrite the MPS parameter Gaviota was memorizing, so it now does expect the next time control at the correct move. (It would be thinking it was still in the first session of this new TC, but who cares.)

Ok, I see. It may work with Gaviota (I think...).

That is how I understood the protocol. It is not explicit that the number of moves is from the start of the game, but you can smell that was the spiri. For instance it says: "At the start of the game, each player's clock is set to base minutes...". Was I wrong with that interpretation? maybe. An english scholar may correct me , but I doubt I am alone. The protocol is explicit that with this command level, each session is the same. It says "In conventional clock mode, every time control period is the same" and the conventional clock mode is the one set by level. Then, the engine cannot be expected to receive different level commands to change different sessions.

That does not necessarily follow. The user could change his mind about which TC he wanted to play. He can change is mind about pretty much everything else, like the time left on the clock, for example (with a time command). He can even change his mind about which side the computer plays! So why not about the TC?

At best, IMHO, this is some sort of undefined behavior and I think it violates the spirit of the command level.

Well, if the "undefined behavior" happens to be the desired behavior, it is "mission accomplished".

For that reason, I think that we should go for a new command altogether: "mlevel" or so, or redefine it with feature, etc. and the old engines that cannot play multiple different sessions should not be used in matches with this feature.

This is for tournament directors to decide. I see no reason to decide it for them by withholding this kludge to do it. I want to have the option to do this, to test my own engine under conditions where it can search deep in the middle-game, and I can speed it up in the end-game. And I want to have a wide choice of opponents to play against. I don't want to have to wait untill one or two people decide to implement this feature.

In any case I would see no reason to use a different level command; what you want would be more easily acheived by making level=0 the defaut for the feature. For engines that exlicitly use the feature it hould be no problem to interpret intra-game level commands as I intend them, and other engines would never have to do it.

They were not designed for that purpose.
I believe it is better if winboard says "sorry, engine X does not recognize multilevel, choose another setup", rather than forcing them play in suboptimal conditions, just plain broken, or at best, a situation that the author did not anticipate.

Here we obviously have a different philosophy. I am a "Yes we can" man...

Otherwise, some wil behave as HGM, some not. It will be up to the testers to find out which ones and it could be a frustrating experience. How many will break as the latest released Gaviota?

Now you are aware of the problem, it would be easy enough to fix it. If testers think it is too frustrating to figure out which engines need the kludge /...AccumulateTC=true, and which engines cannot handle reasonable multi-session TCs at all, they simply should not run this kind of tournament. we laready discussed easy ways to figure out which engines work which way, and perhaps I would publish a list of engines that would work.

Gaviota is not an issue because I can fix it anytime. I used it just as an example.

The problem is that the implementation you propose is not free. In case of more than two sessions, it won't deliver all the information to the engine at the beginning of the game. I believe is important.

Is is not possible to implement both schemes? if the engine accepts it, send a level with all the sessions at the beginning of the game. If the engine doesn't accept that, submit the levels with your proposed scheme. Winboard can manage this with the feature command. Right? You will get the best of both worlds and the Winboard protocol will advance to something more modern and flexible. New engines can adopt the cleaner scheme, and old ones will still have a chance to be supported (if your assumption that many old engines will behave as you predict is correct). I think this could be a good compromise.

Miguel

[H.G.Muller]

This is simiar to that I proposed:

Engines that send the feature level=1 command will get multi-session level commands in stead of normal ones. This includes one at the begining of the game which will specify all sessions inadvance, upto the very last.

But I think it is still better to send them new multi-session level commands at te beginning of each following session anyway, with shifted arguments, as this avoids the problem of having to know how many sessions they will be able to accept. Perhaps there is a user that will request a TC of 1000 session... The scheme I proposed is robust in this respect, and if engine authors want to go through the trouble of changing their processing of the level command such that it can read the multiple sessions, they might as well change it such that the interpretation of these MPS parameters is 'rmaining moves' rather than 'moves since beginning'. In fact it will make life easier for them, because it saves them the trouble of having to program for ridiculously large numbers of sessions, and they could decide to only look a single session ahead.

Perhaps for engines that play through the kludge I should 'translate' the time left on their clock from a previous session to the average move speed of the next session, to prevent games from being decided by the time that was accidentally left over on their last move of the session (e.g. bcuse it as an easy move, or a ponder hit), in cases where an enormous speed-up is requested that they could not see coming. E.g. in 40/40+1+0, where you would have to play all remaining moves after 40 in 1 minute. WB could equate that to 1.5 sec/move, while in the first session there was 60 sec/move, a speed-up of 40. So if an engine would have 3 min left, it could be reduced to 4.5 sec, so it gets 64.5 sec for the rest of the game, not to disadvantage its opponent too much that happened to have a fail low on its 40th move and had only 20 sec left (which will now get 60.5 sec for the rest of the game, in stead of having to play 240 vs 80).

[Miguel A. Ballicora]

This is simiar to that I proposed:

Engines that send the feature level=1 command will get multi-session level commands in stead of normal ones. This includes one at the begining of the game which will specify all sessions inadvance, upto the very last.

But I think it is still better to send them new multi-session level commands at te beginning of each following session anyway, with shifted arguments, as this avoids the problem of having to know how many sessions they will be able to accept. Perhaps there is a user that will request a TC of 1000 session... The scheme I proposed is robust in this respect, and if engine authors want to go through the trouble of changing their processing of the level command such that it can read the multiple sessions, they might as well change it such that the interpretation of these MPS parameters is 'rmaining moves' rather than 'moves since beginning'. In fact it will make life easier for them, because it saves them the trouble of having to program for ridiculously large numbers of sessions, and they could decide to only look a single session ahead.

I like the concept, particularly if you send all the information upfront, and you the engine "informed" with updates. However, the implementation is not compatible with the previous definition of level=1. What I dot not understand is why you do not want to introduce a new feature command such as mlevel or whatever new name you want to give it, rather than redefining what level means. Do you see a problem with a new feature command?

Miguel

Perhaps for engines that play through the kludge I should 'translate' the time left on their clock from a previous session to the average move speed of the next session, to prevent games from being decided by the time that was accidentally left over on their last move of the session (e.g. bcuse it as an easy move, or a ponder hit), in cases where an enormous speed-up is requested that they could not see coming. E.g. in 40/40+1+0, where you would have to play all remaining moves after 40 in 1 minute. WB could equate that to 1.5 sec/move, while in the first session there was 60 sec/move, a speed-up of 40. So if an engine would have 3 min left, it could be reduced to 4.5 sec, so it gets 64.5 sec for the rest of the game, not to disadvantage its opponent too much that happened to have a fail low on its 40th move and had only 20 sec left (which will now get 60.5 sec for the rest of the game, in stead of having to play 240 vs 80).

[H.G.Muller]

I am not aware a level=1 feature existed previously. Where did you find it, and what is it supposed to mean? There is nothing against using another word for this feature; I only picked 'level' because I thought it was still available. And it seems the most logical choice, as it determines something about the 'level' command.

[Sven Schüle]

I am not aware a level=1 feature existed previously. Where did you find it, and what is it supposed to mean? There is nothing against using another word for this feature; I only picked 'level' because I thought it was still available. And it seems the most logical choice, as it determines something about the 'level' command.

There has been no "feature level=xxx" setting up to now. But I think it was very easy to mix this up with the existing "level" command since the name you want to choose seems *not* to be the most logical choice. Look at these examples: ping, setboard, playother, usermove, time, draw, analyze, ics, name, pause. These are names of "feature" settings where the value 1 means that the engine understands the command that has the same name as the feature.

So if you name a feature "level" then it would seem obvious that reporting a value of 1 shall indicate that the engine understands the "level" command. But in spite of that, the semantics is totally different, and that's why the name of the feature setting should be different from "level" in order to reflect that setting it to 1 indicates the engine understands multi-session time control settings.

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.

Sven

[Miguel A. Ballicora]

I am not aware a level=1 feature existed previously. Where did you find it, and what is it supposed to mean? There is nothing against using another word for this feature; I only picked 'level' because I thought it was still available. And it seems the most logical choice, as it determines something about the 'level' command.

Sorry, my mistake, I got confused by your phrase when you talk about level=1. It led me to believe that you were talking about a preexisting level=1, since level already exist. My sentence should be rephrase as "However, the implementation is not compatible with the previous definition of level".

Miguel

[Miguel A. Ballicora]

I am not aware a level=1 feature existed previously. Where did you find it, and what is it supposed to mean? There is nothing against using another word for this feature; I only picked 'level' because I thought it was still available. And it seems the most logical choice, as it determines something about the 'level' command.

There has been no "feature level=xxx" setting up to now. But I think it was very easy to mix this up with the existing "level" command since the name you want to choose seems *not* to be the most logical choice. Look at these examples: ping, setboard, playother, usermove, time, draw, analyze, ics, name, pause. These are names of "feature" settings where the value 1 means that the engine understands the command that has the same name as the feature.

So if you name a feature "level" then it would seem obvious that reporting a value of 1 shall indicate that the engine understands the "level" command. But in spite of that, the semantics is totally different, and that's why the name of the feature setting should be different from "level" in order to reflect that setting it to 1 indicates the engine understands multi-session time control settings.

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.

Sven

I agree, and the spirit of HGM's clever rescue approach for old engines won't change a bit.

Miguel

[H.G.Muller]

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.

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.

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.

[Sven Schüle]

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

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]

I see no benefit in using a different keyword for the same command, depending on the number of arguments it has. 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.