Suggestion for simple extension to the UCI Protocol

[Jaap Weidemann]

You could have muliple threads and processes...

Just as you could have multiple cores on one die and multiple processors on one motherboard.

[Daniel Mehrmann]

You could have muliple threads and processes...

Just as you could have multiple cores on one die and multiple processors on one motherboard.

Exactly!

So Cores is the smallest unit which used by both: threads and processes.

Come one, this is no question.

Best,
Daniel

[BubbaTough]

I must admit, I don't have any idea what UCI philosophy is, I merely use it. Those that dedicate their own time to developing / supporting UCI are free to ignore me.

I also don't mind being bashed a bit for my "pragmatic" kibitz suggestion (and no...i don't need to hear why it is soooo philisophically different from 'info string' because 'info string' is...err...not really a GUI command but something really different).

But Draw, Resign, and being aware another engine/player is offering a draw are pretty important chess actions...and ones that are pretty useful for engines to have implemented for any number of reasons. Many engine builders and tournament runners work around the absense of these by taking advantage of features of Jaap's polyglot version or resign options in Arena, or maybe even some draw detection in the newest winboard version, or any of a number of other techniques, but really they should be supported directly in UCI in my opinion so that engine makers aren't stuck relying on the 'chess broker tools' making important chess decisions for them and can instead develop their own algorithms for this aspect of chess play. And yes, I believe offering/accepting a draw, or resigning, is as legitament a chess decision as what move to make.

-Sam

[Daniel Mehrmann]

UCI_EngineCores would be the best.

Hi Daniel,

As I explained above the use of a "UCI_" prefix option would render such an option useless in a GUI that does not yet support the new command in question.

Jaap

the UCI_ keyword just stays for static predefined options.

The engine offers it to the gui like all other options. The GUI "can", means must support it, now use this option while sending the states offered by the option, in this case the number of cores which should be used.

Please read the UCI documentation exactly.

Best,
Daniel

[Jaap Weidemann]

Hi Daniel,

Please read the UCI documentation exactly.

I assure you I have.


What I am trying to avoid is non-backwards compatibility.

If the GUI gets an unknown Option with the prefix "UCI_", it should just ignore it and not display it in the engine's options dialog.

This means that if the engine sends an option with the name "UCI_EngineCores" and the GUI does not support this option, it will just ignore it and not display it in the engine's option dialog. The obvious result being that the user is unable to set number of threads (or processes or processors or cores) that the engine should use.

Jaap

[guyhaw]

Has the UCI definition fully taken into account the requirement to run the engine in 'batch mode', i.e., not interactively.
I am in fact running SHREDDER10 in batch mode to analyse some positions.
I believe the 'stop' command stops the search immediately, and maybe 'quit' has the same effect. What I need is to quite the job, or continue with the next job, only after the specified search has been done.
We have also had some corruption of SHREDDER's results by what we think are control characters in the input-stream, maybe end-of-file characters. I wonder if others have experienced this?
Guy