Author: Michael Yee
Date: 06:44:58 03/15/05
Go up one level in this thread
On March 15, 2005 at 03:25:00, Dieter Buerssner wrote:
>On March 14, 2005 at 12:45:22, Michael Yee wrote:
>
>>The protocol proposal has been updated to reflect several good
>>comments/suggestions.
>
>I did not have time, to read it carefully.
I'm probably going to make a summary view that highlights key differences from
UCI better.
>Few random thoughts, that came to
>mind: I did not see multi-PV: probably overlooked it, if not should be added.
>Searchmoves should be optional for the engine (as is multi-PV). It is not, in
>UCI, still many engines don't support it (probably because the engine authors
>found that it is a bit work to implement, also I think no other GUIs than all
>the Shredder Classic versions supports it).
>
It supports multi-PV (through standard option "MultiPV" and "info multipv 1
...". However searchmoves looks mandatory as currently specified. It makes sense
to have another standard option like XCI_SearchMoves to indicate if the engine
supports it. (The feature itself seems useful for people wanting to do a
constrained analysis with the engine.)
>From your protocol I see not how pondering should work. Note, that however you
>do it, it will probably be more complicated to implement from engine side, than
>the much critisized UCI pondering. Perhaps one could think of a method that
>supports both, UCI go ponder with ponder move/ ponderhit and a more general go
>ponder without move.
>
Please see my reply to Vasik. I suppose both forms could be supported, but one
question. Where does the suggested ponder move come from? Taken from the
engine's own previous thinking lines?
One way both can be supported is to provide a suggestion with "go ponder". Then
the engine either gets a "stop / make xyz / go (think)" sequence if the
suggestion was wrong. Or it gets a "ponderhit" which means the suggestion was
correct, it should officially make the move on it's internal board and enter the
THINK state.
>Your description of level seems to be missing 40/90+15 sort time controls.
>
Thanks, this is a good catch.
>Setoptions seem to miss many things of UCI. Define some general options, that
>should always mean the same (much like UCI): hash, TB-path, clear hash (this
>last is not in UCI). Additionally to the UCI type options, options for file
>and/or path names might be useful.
>
All these ideas are good (especially the path type).
>I see no way, how a GUI could drive a game analysis (which would include some
>time control, not infinite) and the engine beeing aware of it (the reason
>UCI_AnalyseMode was added). Also, who would a back to front analysis look?
>
Another good catch. Instead of "go infinite", "go analyze maxdepth ... maxtime
..." would be more general.
The idea of supporting backwards analysis (or even standard analysis and other
things unrelated to playing an actual game) is very interesting. Here is an
idea:
For game-related operations (e.g., backwards analysis on the current game), we
could have options/commands (similar to Clear Hash) that permit a generalized
form of output. For example,
option name "Backwards Analysis" type button output
would mean that if the user clicks on "Backwards Analysis", yace would analyze
the current game, then send generic info strings to the GUI terminated by a
readyok command:
info [Event ...]
info ...
info [Result ...]
info
info 1. a3 {this is a stupid move} e5
...
readyok
Then the GUI can capture all the output and display if for the user (to save or
whatever).
More radically, we could even have "input requests" that the engine could use to
get parameters from the user (like Steffen Jakob's suggestion). For example,
during init, the engine can list all the kinds of input it might need for
various button commands:
input name Filename prompt "Please enter the filename" type filename
input name Depth prompt "Please enter depth" type combo ...
Then an option can really be the specificaion of a dialog box:
option name "Backwards Analysis" type button input Filename input Depth
>Lance mentioned some internalization issue. I also thought about this, when I
>implemented UCI for the first time. But I see no solution - Lance, do you have
>any idea in mind? The only thing, I can think of would be to note the
>(preferred) language from GUI to engine at the first command. An engine might
>want to give options in different languages.
>
>Another internationalization issue: May strings contain special chars? My engine
>reports my name as "Dieter Buerssner", which is a typical transliteration to the
>English alphabet of the proper "Dieter Bürßner". Shredder Classic can display
>the proper spelling on my computer, but I always wondered what a user on say a
>Russian or Chinese PC would see? Also, such things might be needed to be defined
>for each OS seperately? Which would make them rather horrible for an engine
>intended to be very portable.
>
>>Even if people are dead set against introducing a new protocol into the mix, I'm
>>curious what UCI fans think about some of the extensions. Specifically,
>>
>>- describing what options mean,
>
>Yes, should be there (was also discussed as an addition to UCI).
>
>Writing a GUI supporting all this will probably not be an easy task. Peter
>Schäfer, would it be a lot of work to add to Jose? I know, that you did not like
>the idea of a new protocol ...
>
>Best regards,
>Dieter
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.