Author: Dieter Buerssner
Date: 11:03:20 05/24/05
Go up one level in this thread
On May 24, 2005 at 09:28:17, Thomas Mayer wrote:
>Hi Daniel,
>
>> Well, the new version of UCI support a analyze mode:
>>
>> // if the engine supports the "UCI_AnalyseMode" option and the next search is
>> // supposed to be an analysis, the GUI should set "UCI_AnalyseMode" to true
>> // if it is currently set to false with this engine
>> setoption name UCI_AnalyseMode value true
>
>> Homer support this too, but at the moment there a no gui avaible which
>> support this nice feature.
>
>that's funny, UCI was always thought as stateless protocol and now they
>backinvent states this way ?! :) Well, that it does not work fully without
>states is clear, think about the ponderhit command.
>Anyway, good to know that this feature exists, I will implement that in my
>version of epd2wb -> what I did not understand: So the UCI_AnalyseMode must be
>set before EVERY search which is an analyse ? So it should look like this ?
From the protocol document, this it not really clear. I think, the intention was
to send it just once, and the engine remembers it as a state. Much like the
Ponder option (which the engine can use to adjust its time allocation for ponder
games). We should ask SMK to clarify the wording. Anyway, it should not hurt to
send it before any search.
* <id> = UCI_AnalyseMode, type check
The engine wants to behave differently when analysing or playing a game.
For example when playing it can use some kind of learning.
This is set to false if the engine is playing a game, otherwise it is
true.
BTW. It might also be the other way around. The engine might want to do some
specific learning during (especially backwards) analysis, which may be useless
or even slightly hurting during normal games. Some engines might need to switch
off asymmetric evaluation. For GUI driven analysis, the engine cannot detect
that it is in analyse mode by other means in general. For example the analysis
might be driven with a typical game time control. (The same problem exists with
GUI driven analysis for the WB protocol).
>By the way: The reason why I send an "ucinewgame" before every position is
>simple: just to keep sure that the hash is cleared. Else solutions are not
>reproduceable at all.
It is of course no guarantee, that the engine will clear the hash tables. Even
if it supports ucinewgame (which many engines will not). Other things, for which
ucinewgame can be useful: have a convinient point to do some learning, perhaps
you want to store games in an engine specific database, perhaps you want to
increment some number in a log file, ...
I think, Yace never clears HTs under UCI, unless the user hits the "clear hash"
button. I don't see much of a disadvantage for this, either. In test-suites, it
might yield in non reproducable node numbers - but really no problem. If I
really want to have reproducable node numbers, I will use some engine specific
test routines. Those who prefer to use a tool, like epd2wb, would need to judge
for themselves, how to approach the problem of possibly not reproducable node
numbers.
It might be interesting to note, that CB UCI implementation more or less
assumes, that Clear Hash is a hardcoded option with a defined meaning, and will
send it for new games. But Clear Hash is not defined like this in the UCI
protocol, it is just given as an example. It might have been a good idea, to
have this hardcoded like few other options (preferably with a name like
"UCI_Clear_Hash").
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.