Winboard "level" command issue

[jdart]

I've been looking a bug report of bad time usage by Arasan in a game with long "tournament" time control (e.g. 40 moves in 120 minutes).

I don't use this mode very often but I tried running a match in Winboard 4.2.7a with this command:

winboard -debugMode true -tc 120 -mps 40 -ponder -mg 2 -ponder -zp -fcp "c:\chess\engines\arasan11.3\arasanx -H 256000 -ics -t" -scp "c:\chess\engines\alaric0707\alaricwb707.exe" -sd c:\chess\engines\alaric707

Now, I see Winboard send the command "level 0 120 0" to the engine. This is game in 120 minutes. Shouldn't it be "level 40 120 0"? The docs say that if you have -mps it sets a time control interval (number of moves) and the default is supposed to be 40.

--Jon

[Will Singleton]

Jon,

Yes, it's a bug. Just replace the mps command with -inc -1, and it'll work right. (mps defaults to 40).

Will

[hgm]

I am not sure this is a bug. More a cumsy way of defining the meaning of the command-line options. WinBoard TC modes need either the -mps or -inc parameter to be ero. If they both are non-zero it has to resolve the conflict, and decide if it will use incremental mode (ignoring the mps) or classical mode (ignoring the increment) by itself.

The algorithm it uses to do this is that in case an increment is specified, it zeroes the -mps parameter.

Now that you don't specify -inc on the commnd line does not mean that it is not specified, as WinBoard always remembers all its settings from the previous run in the winboard.ini file. Thus, if the previous run had -inc specified, the current run will have it specified as well. So you have to switch off incremental mode explicitly, by using -inc -1.

This is the price you pay for remembering settings. Every setting that is remembered will have to be explicitly reset when you don't want it anymore. I don't see how this can be avoided.

I always use the menu for setting the TC, that automatically adapts all three parameters (-mps, -tc and -inc).

Note that -mps defaults to whatever you used last, as it is also remembered in the winboard.ini file. Which does need to be 40. It could in fact very well be 0, if you last used an incremental TC. Only on a virgin run when winboard.ini does not exist yet will it default to 40.

[jdart]

That's an awful behavior. I'd definitely call it a bug not a feature, since the docs do imply that you can set -mps or -inc on the command line with predictable behavior (not depending on the past state). And that would be consistent with how every other command-line driven tool works (I know Winboard is mostly a UI but some of us script its commands).

--Jon

[hgm]

But most command-line tools are not remembering their settings. The command line you give is not the full command line, but is merely appended to the command line(s) you gave before.

If the documentation is not clear about this, it should be updated.

I guess the major design flaw is the choice of the command-line parameters. If the -mps and -inc options are mutually exclusive, they should have been the sme option. In fact t would have been better if the entire TC stuff would have been a single string option. So that you could give

winboad -tc 5+1

or

winboard -tc 2:30/40

for 5 min + 1sec/move or 2.5 min per moves, respectively. Then the -mps and -inc options could be deprecated.

[krazyken]

I am not sure this is a bug. More a cumsy way of defining the meaning of the command-line options. WinBoard TC modes need either the -mps or -inc parameter to be ero. If they both are non-zero it has to resolve the conflict, and decide if it will use incremental mode (ignoring the mps) or classical mode (ignoring the increment) by itself.

The algorithm it uses to do this is that in case an increment is specified, it zeroes the -mps parameter.

That algorithm is the bug here. It should use the parameter specified last.

[hgm]

I agree that this would be more convenint in this case, but it would violate th general philosophy of the command-line-option processng, namely that the new commnd line is appended to the saved options before processing the options. The options can come from many sources, command line, winboard.ini file, indirection files specified in the command line, the engine ftype-in fields in the startup dialog, the parameter to the -fcp or -scp option. As a result there is no clear concept of the option 'specified last'.

[jdart]

Or as another poster noted, if you just took the last command (-mps or -inc) as the effective one, you wouldn't have this problem. If I used -inc before but now I'm putting -mps on the command line, I think it's reasonable to assume I want -mps now. The implementation could do this just by zeroing the "other" parameter whenever it sees one of (mps, inc).

--Jon

[hgm]

Except that the parameters are handed as a a structure of settings to the application, and there is no way to know which occured before the other, or what its source was.

[bob]

But most command-line tools are not remembering their settings. The command line you give is not the full command line, but is merely appended to the command line(s) you gave before.

If the documentation is not clear about this, it should be updated.

I guess the major design flaw is the choice of the command-line parameters. If the -mps and -inc options are mutually exclusive, they should have been the sme option. In fact t would have been better if the entire TC stuff would have been a single string option. So that you could give

winboad -tc 5+1

or

winboard -tc 2:30/40

for 5 min + 1sec/move or 2.5 min per moves, respectively. Then the -mps and -inc options could be deprecated.

I think the idea of "remembering" is bad. _really_ bad. And I'd bet that this causes more problems than any other issue. Position learning in chess engines has led to more errors, false reports, false claims about quick solution times and such than I care to remember.

I would prefer this be done with a more traditional approach, such as .xboardrc or whatever so that the user is responsible for setting up the defaults, and changing the defaults whenever desirable.

There is a definite hierarchy for this. You first parse the .xboardrc file, then you parse the command-line options which override the .xboardrc if given, then you let the usere point and click to override both if they so choose. Which is how most other application packages work. This gives the same effect without the confusion of long-term memory that a user might not be aware of.

Just my $.02...