Winboard Forum

This poll is mainly meant for WB engine authors. There is a discussion ongoing in this thread: http://www.open-aurec.com/wbforum/viewtopic.php?t=49792 about possible ways to design and implement a new feature that allows for more flexible time control settings, like "first 40 moves in 20 minutes, next 20 moves in 5 minutes, then 20 moves in 3 minutes, finally 2 minutes for rest of game" (just to give any example). While originally that thread was about suspicious behaviour of a couple of WB engines that has been found to be caused by a common problem w.r.t. to counting moves when in "force" mode, the discussion now moved to the partially related topic of multi-session time control. H.-G. Muller plans to change (extend, redefine) the specification of the WB command "level" such that it can be used for that new feature, and there are different opinions about the realization.

What has been agreed at least is that engines that want to support that new feature acknowledge it with an appropriate "feature xxx=1" setting, where the naming for "xxx" is still being discussed controversely.

My intention is now to find out what other engine authors think about these possible ways that can be taken. While the poll only directs to one aspect, using a new command like "mlevel" for the new feature vs. "reusing" the old command name with an extended definition, the discussion shows that there are also other things that can be decided this or that way, which can't fully be covered by one poll of course.

Since mainly three persons participated in that part of the discussion up to now, I thought it could be an option to ask for more opinions.

It may be a good idea to read that thread first before voting, although it is not recommended.

Sven

Sven Schüle wrote:It may be a good idea to read that thread first before voting, although it is not recommended.

Oops, my English at night ... what I meant was: "although it is not a requirement". Most will have understood anyway, I hope.
Sven

I see, so now we are pretending now that this is a democracy, eh?

Let me tell you how it really works: If one or two people disagreed with me, I would assume that it was just a matter of them having a different personal preference.

If 90% of all people would disagree with me, I would assume that they needed to be educated.

Only if 99% would disagree with me, I might start wondering if I had properly weighted the various pros and cons.

The main weakness of democracy is that it gives the power to people that might not be aware of all the issues, or in fact not aware of any, or just misunderstand what the issue is about. For instance, are any of the voters that voted for anothe keyword than level aware of the fact that Tim Mann himself proposed long time ago to use the same keyword (i.e. level) with arguments for multiple sessions? And that there exist WB engines that actually implement this command already, such as BlackBishop?

How am I to weight the opinion of people that were not aware of that? How am I to weigth the opinion of people from which I do not know if they were aware of that?

The problem is further compounded by the fact that the interest of engine authors does not fully coincide with that of GUI and protocol developers. This is similar to putting it up for voting if one person in the room has to give up his money to all the others. I expect many authors to vote for a new command, just so it is guaranteed they can ignore the changes / extensions. (Even withouth first investigating if the changes would hurt them.) And having people ignore the extensions is not in the interest of the future development of WinBoard protocol...

I never assumed that the result of this poll would be relevant for you. Maybe it will only be relevant for me and a few others.

I also do not intend to establish WinBoard forum polls as a new way to decide about changes of the WB protocol, or similar important interfaces. It is just a poll, to get a feeling of how others may think about that topic.

However, all voters that would appreciate it if it *were* relevant for you are encouraged at least to comment on their votes.

Sven

Well, arguments would do better than votes in having any impact. Most importantly, it would be very inteersting to know why people prefer to have two different commands meaning exactly the same thing:

level 40 5 0

and

mlevel 40 5 0

(say).

If they could not explain that in a convincing way, a large vote in favor of this would only convince me that they are on average so misguided that it is not worth paying attention to them at all. People voting that the Earth is flat in general meet with contempt, nowadays, and the more massively they vote for it, the more contempt they generally reap as a group...

H.G.Muller wrote:Well, arguments would do better than votes in having any impact. Most importantly, it would be very inteersting to know why people prefer to have two different commands meaning exactly the same thing:

level 40 5 0

and

mlevel 40 5 0

(say).

If they could not explain that in a convincing way, a large vote in favor of this would only convince me that they are on average so misguided that it is not worth paying attention to them at all. People voting that the Earth is flat in general meet with contempt, nowadays, and the more massively they vote for it, the more contempt they generally reap as a group...

People who are interested in finding out whether the comment above describes the most important part of the discussion or not are invited to read the thread I already mentioned:
http://www.open-aurec.com/wbforum/viewtopic.php?t=49792

Sven

If they could not explain that in a convincing way, a large vote in favor of this would only convince me that they are on average so misguided that it is not worth paying attention to them at all.

In open source projects it is very important to obtain a consensus among the community.

But of course it is not a true democracy. Code talks. Arguments from engine and GUI authors should weigh the most.

I personally believe that voting is the best way to make a decision when when people have disagreement after being aware of and understanding each other's arguments...

I only expect the level command to appear once before telling the engine to start playing and never in between. I honestly don't know if Buzz or Dirty will work fine receiving another level command. In addition, I don't like the idea of sending level commands half-way in the game. The engine should be fully aware of what time control it is playing in just as a human would be before starting the game. There are two solutions to this:

• put all the time controls on a single line with the level/mlevel command
• multiple level/mlevel commands at the start of the game

I don't like the first option because it makes parsing more difficult and it is not robust. For example, say you wanted to run some kind of insane 100TC game with like 1 move per session in 1 minute for first TC or 2 moves per session in two minutes for second TC ect... you might end up with problems with engines that read each line as fixed sized buffers (either the text read in might be cut off and some indeterminate behavior will happen or perhaps the engine may crash). The solution of having a buffer so big that you will never have problems is not ideal. Therefore I like the second approach sending multiple level/mlevel commands at the start of the game. I propose using level to send the first TC and consecutive mlevel commands to send additional TCs and it will look somewhat like this:

level ...
mlevel ...
mlevel ...

Then the final TC can reccur if necessary until the end of the game.
I like this approach because parsing is easy, it is robust, and it is very clear what state the time control is in. For example if you wanted to give an engine a new time control you can send the level command to reset whatever time control it had previously and add the first time control. Then you can add additional time controls with mlevel.

I also believe that if an engine can't keep track of the move count correctly, it is a bug. I believe the problem of having messed up TCs after getting a new position with FEN for example happens because it wasn't clearly specified in the original WB protocol.

I think Pradu's idea is the best, though maybe a bit unconventional. It doesn't change the meaning of the level command, but the mlevel command does not have redundancy. I'd say it's easier to parse though.

That said, I think it would be better to completely rethink time control. I have zero interest in multi-session time controls, and will probably not implement this part of the protocol. I think time odds matches are more relevant.

Zach Wegner wrote: I have zero interest in multi-session time controls, and will probably not implement this part of the protocol

Hmm there is a special kind of time control I would be much interested in seeing implemented now that polyglot and its books are more closely linked to winboard :

I wish i could set up matches where the time definition begins once an engine leaves his book and begins to work on its own.

Something like 60 seconds per move for the first ten moves after book, then 10 seconds per move for the next ten moves and so on.

Could it be feasible ?

Marc

This is actually the way some broken engines count (which started this whole discussion). By making this an official time-control mode, such engines would likely be fixed by letting them play in this mode...

The switch that you want is ordinary multi-session TC, 10/10+10/1, the only thing special is that you want to start counting after getting out of book. It would be easy to make an option that accomplishes this. Another way, not requireing a new option, would be to generate out-of-book positions by playing two opening engines against each other, and save them as FEN. When WB then plays from a position file, it will always start counting at move 1 as far as TC is concerned. So you could do it with a normal multi-session TC then.

For time-odds, the engine does not have to be aware of anything. This is already fully operational.

I have my doubts on Pradu's proposal: if you can handle an arbitrary number of lines, using 'mlevel' as a continuation symbol, surely it would not be so much more difficult to use a space at the end of the line as a character indicating that the line continues in stead?

I think a very good defence against users specifying a ridiculous number of sessions, is to have the engine simply ignore the later ones. If you have parameters for 100 sessions, how would you use them anyway to determine how long you would think on your first move? What will happen after 50 moves will hardly be relevant, then.

This is why I think that re-sending the level commands with shifted arguments is much easier for the engines. They would not have to worry about remembering an arbitrary long list of session parameters, they would all be re-sent in due time when they become relevant. The only sensible way I can think of to use the parameters for future sessions is to check if there will be a ridiculous speed up in the next session (it is usually best to allocate your time such that there is a moderate speed-up during the game anyway), and if there is (say 40/40+20/1) consider the current+next session like they were one (so play o a schedule for 60/41 until move 40).

H.G.Muller wrote:Well, arguments would do better than votes in having any impact. Most importantly, it would be very inteersting to know why people prefer to have two different commands meaning exactly the same thing:

level 40 5 0

and

mlevel 40 5 0

(say).

If they could not explain that in a convincing way, a large vote in favor of this would only convince me that they are on average so misguided that it is not worth paying attention to them at all. People voting that the Earth is flat in general meet with contempt, nowadays, and the more massively they vote for it, the more contempt they generally reap as a group...

Your example here includes only one TC. The discussion was around modifying/expanding/redefining "level" (or not) to have more than one TC. Only with more than one TC, mlevel will be relevant. With only one TC, level will be used. At least, that is what was mentioned in the other thread.

Miguel

Let me rephrase the question then:

Why would you define two commands that mean the same, and then arbitrarily use only one of them, by adding an extra superfluous rule on top of an extra superfluous definition?

Apparently you do not only want to have two commands that the engine would understand the same, you also want to bother the GUI with figuring out which of the two to send when.

This gets pretty close to an "over-my-dead-body" kind of thing...

Obviously you do not even try to understand what Miguel and I mean, and I'm tired to explain the same again and again.

And since the current votes are below the "99% disagree" threshold that you have defined (10:1 = 90,9% if I assume that you have already voted) I already know the outcome of your decision.

So I quit for now. Maybe others want to continue the struggle.

Sven

H.G.Muller wrote:Let me rephrase the question then:

Why would you define two commands that mean the same, and then arbitrarily use only one of them, by adding an extra superfluous rule on top of an extra superfluous definition?

As I already said, they mean the same according to your interpretation.

Apparently you do not only want to have two commands that the engine would understand the same, you also want to bother the GUI with figuring out which of the two to send when.

This gets pretty close to an "over-my-dead-body" kind of thing...

I do not know what you mean by this, but I am sure it can be skipped.

Look, I am thankful that you are trying to improve winboard and I acknowledge it takes a lot of work. The guy who writes the actual code have the last word. Whatever you decide it is going to be better than what we have now. I assume, since you brought this up, that you wanted to exchange ideas. Since I am a user of this free software, the least I could do is to give you my perspective.

Miguel

H.G.Muller wrote:I have my doubts on Pradu's proposal: if you can handle an arbitrary number of lines, using 'mlevel' as a continuation symbol, surely it would not be so much more difficult to use a space at the end of the line as a character indicating that the line continues in stead?

This approach complicates the issue more than it needs to be. Having a space at the end of the line puts the engine in a "special mode" where it needs to expect more lines. Also it makes it harder to read by a human for debugging (is there a whitespace there?). If you propose arbitrary inputs for each line, parsing the input becomes more complicated. Also I bet many engines (using sscanf, although there are probably many that use tokens instead) are setup in a way where they first get a line, then scan the line for a command, then match the command with an operation with if elseif elseif comparisons and then parse a pre-determined number of arguments of the command and do whatever other operations necessary. I indeed do this for every command received by the engine from the GUI in the original Winboard Protocol with the exception of some hacks to get it to read possible variable arguments from the level command (seconds may be specified or not, and even here a command is present at the beginning of the line). Summary of some reasons why having level with multiple mlevels is better than a single level command:

• Consistent with other commands in the original Winboard Protocol ([command_name args...] on every line).
• Number of arguments and format of arguments known ahead of time (after scanning the type of command). This is useful for sscanf implementations.
• Better for human readability.
• Easier to implement within existing Winboard Protocol implementations relying on sscanf or tokenizing implementations relying on commands on every line with a command name and then arguments.
• Does not require a special mode and/or special parsing mechanisms.

I think a very good defence against users specifying a ridiculous number of sessions, is to have the engine simply ignore the later ones. If you have parameters for 100 sessions, how would you use them anyway to determine how long you would think on your first move? What will happen after 50 moves will hardly be relevant, then.

To give an example so that you can see the point... lets say you had a TC 40 moves in 40 minutes first then a second TC with 10 minutes for all moves. I'm sure you could use information about the second TC to formulate a better time-management during the first TC. In this example you could assume a "compiled TC" such that the TC game in 50 minutes with the constraint that 40 moves must be played in the first TC and modify your time management appropriately. If your 50 minute time management satisfies the 40-move constraint, you may simply use your 50-minute time management. If it doesn't satisfy the 40-move constraint then use a time control suitable for staying within the constraint.

This is why I think that re-sending the level commands with shifted arguments is much easier for the engines. They would not have to worry about remembering an arbitrary long list of session parameters, they would all be re-sent in due time when they become relevant. The only sensible way I can think of to use the parameters for future sessions is to check if there will be a ridiculous speed up in the next session (it is usually best to allocate your time such that there is a moderate speed-up during the game anyway), and if there is (say 40/40+20/1) consider the current+next session like they were one (so play o a schedule for 60/41 until move 40).

So you just gave an example yourself of when knowing subsequent TCs will be useful... Regardless, I think it is a bad idea to build an avoidable limitation into the protocol, such as not being able except what all the new time controls will be. The engine programmer should decide how he will use all of his available information.

Given that an engine is bug-free and implements the protocol correctly, what other advantages does sending multiple level commands throughout the game have over a level command with subsequent mlevels at the beginning of the game?

From your post I see one major pro: The engine would not have to worry about remembering an arbitrary long list of session parameters or keeping track of the sessions.
And one major con: built-in limitation in the protocol such that the engine will not have knowledge of future time controls

From my post I see one major pro: The engine will know all session parameters and the engine programmer may decide himself how to use the information.
And one major con: engine must keep track of multiple time controls

There is no reason we can't combine both approaches to gain the advantages of both; however, the information provided to the engine will be redundant and it makes the protocol more complicated. In addition I believe the pros of giving the entire TC upfront outweighs the cons of doing this (your opinion probably differs).

Miguel A. Ballicora wrote:As I already said, they mean the same according to your interpretation.

And that is wrong: what they mean is decided by the code in the engine that parses the multi-session level command.

So show me some code that would not result in the engine behaving the same on parsing an mlevel command with 3 parameters as it would on reception of the normal command. If you could do that without intentionally sabotaging the code through incorporating statements like if(sessionCnt>1) exit(1); you might have a point. Otherwise you are simply wrong.

Pradu, I really think this is a bit of a non-issue. The code to parse a multisession level command on a single line that was already read into a buffer is:

Code: Select all

if(strcmp(inbuf, "level ") == 0) {
    char *p = inbuf + 7; // position after the word "level "
    int n, mps, min, inc, sec;
    while(sscanf(p, "%d %d:%d %d", &mps, &min, &sec, &inc) == 4 ||
          (sec = 0) || sscanf(p, "%d %d %d", &mps, &min, &sec, &inc) == 3) {
        for(n=0; n<3; n++) while(*p && *++p  !=  '  ');
        tc = 60*min + sec;
        // process next (mps, tc, inc) triplet.

    }
}

I seriously doubt if that could be simplified by use of 'continuation' mlevel commands. On the contrary, any code that could handle that scheme is likely to be two times as long.

Human readibility does not carry much weight here, and more so for the GUI developer than for the engine author or tester: you know what TC you entered, and the only thing you would have to read is how the engine understood it, for which purpose you can have the engine print it in any format you like. Note furthermore that the readability is not as bad as it seems, as the INC parameters of all sessions but the last must always be zero. These redundant zeros function as punctuation.

Look, I am not crazy about this format, if it were upto me I would prefer something like the Crafty 'time' command, which would use 40/40+25/15 to indicate multi-session, like it would appear in the PGN tags. Especially the redundant INC parameters make it a really ugly command. But it was defined before, and people did implement it this way. So I think there should be really good reasons to abandon it.

H.G.Muller wrote:Pradu, I really think this is a bit of a non-issue. The code to parse a multisession level command on a single line that was already read into a buffer is:

Code: Select all

if(strcmp(inbuf, "level ") == 0) {
    char *p = inbuf + 7; // position after the word "level "
    int n, mps, min, inc, sec;
    while(sscanf(p, "%d %d:%d %d", &mps, &min, &sec, &inc) == 4 ||
          (sec = 0) || sscanf(p, "%d %d %d", &mps, &min, &sec, &inc) == 3) {
        for(n=0; n<3; n++) while(*p && *++p  !=  '  ');
        tc = 60*min + sec;
        // process next (mps, tc, inc) triplet.

    }
}

I seriously doubt if that could be simplified by use of 'continuation' mlevel commands. On the contrary, any code that could handle that scheme is likely to be two times as long.

Where does it handle newlines? What if like most implementations you read one line at a time at the top of a command loop - do you have to create a special mode of operation just to handle this command to figure out what to do?

Code: Select all

if(!strcmp(command,"level"))
{
   resetLevel();
   addLevel(line+6);
}
else if(!strcmp(command,"mlevel")) addLevel(line+7);

Your code in the same modular format:

Code: Select all

if(strcmp(inbuf, "level ") == 0) {
    char *p = inbuf + 6; // position after the word "level "
    resetLeveL(...)
    addLevel(...)
    while(some condition and new mode of operation to handle newlines)
   {
        with some hack to skip three numbers
        addLevel(...)
    }
    // What if you receive another command while in the new mode of operation? Make a goto jump to the command parsing loop?
}

Modular implementations are well supported with the level/mlevel format and it isn't really that much longer (probably shorter because parsing in addLevel() is probably similar and doesn't require additional hacks) and it is also clearly twice as simple to support the level/mlevel format. Now what about modular tokenizing implementations such as ones in ZCT where it relys on a hashtable lookup of a command for every line of input?

Human readibility does not carry much weight here, and more so for the GUI developer than for the engine author or tester: you know what TC you entered, and the only thing you would have to read is how the engine understood it, for which purpose you can have the engine print it in any format you like. Note furthermore that the readability is not as bad as it seems, as the INC parameters of all sessions but the last must always be zero. These redundant zeros function as punctuation.

It should as people read raw log files often and things may go wrong. Even though it may not carry much weight, it is a problem that can clearly be avoided using level and mlevel and I see no reason why not to avoid it.

Look, I am not crazy about this format

You should be as an interface designer. A lot of effort will be replicated by many people when implementing the protocol. Also taking into account that engines far exceed the number of GUIs, the protocol must be made to make engine programming the simplest.

If it were upto me I would prefer something like the Crafty 'time' command, which would use 40/40+25/15 to indicate multi-session, like it would appear in the PGN tags. Especially the redundant INC parameters make it a really ugly command. But it was defined before, and people did implement it this way. So I think there should be really good reasons to abandon it.

There are really good reasons to abandon it. Creating a design that avoids problems when it is possible to do so is a really good reason. TC tag is not one of the required standard tags in a PGN so we don't need to consider the implications on how to store games like this yet (a possible option for large TC games, add multiple PGN TC tags -- although this differs from the framework described in the PGN standard-- for not as many TCs use PGN method). We are not discussing an existing design for PGN tags but a new framework for the Winboard Protocol. The protocol should work regardless of game storage format for a particular GUI. GUIs who can only give a limited number of TCs can enforce this rule by only allowing the user to specify a certain number of TCs.

What are your comments on the other disadvantages of this approach (consistency with other Winboard Protocol commands as seen by the engine <command tag followed by arguments>, no requirement for special mode of operation).

The code I gave supposes the next line is read into inbuf, null-terminated, as usually happens at the top of the command-parsing loop. No special treatment of newlines is needed, as the command is not multiline, and sscanf does never read beyond a null character. Your code only looks shorter because you failed to include the code for AddLevel(), which is 90% of my code. In modular format, my code would look:

[code]if(!strcmp(command,"level"))
{ char *p = line+7;
resetLevel();
while(addLevel(p)) p = skip3(p);
}
[/quote]

I don't think that code like that is such an insurmountable obstacle that it should have any impact on protocol design. If people do not know how to skip 3 numbers in a string, they should not take up Chess programming...

Well, if I am going to break compatibility with existing multi-level commands, I would prefer

level 40 40+25/15+5 1

to signify 40/40+25/15+5+1, which in the existing format woud have been

level 40 40 0 25 15 0 0 5 1