Author: Vasik Rajlich
Date: 04:17:00 03/16/05
Go up one level in this thread
On March 16, 2005 at 01:26:09, Dieter Buerssner wrote: >On March 15, 2005 at 08:39:00, Michael Yee wrote: > >>The way I envisioned pondering was this way: >> >>- engine remembers "official" state of its internal board >>- engine can temporarily make a predicted move >>- engine outputs regular thinking lines where the first move in the pv is always >>the pondermove >>- when engine gets next move command, it can decide for itself whether it >>predicted correctly, etc. >> >>This approach seems pretty general (and doesn't add any new commands), e.g., an >>engine can change its ponder move and alert the gui. >> >>An alternative solution would be to have a special style of "info" used during >>pondering, e.g., >> >>info pondermove move ... > >Please show an example with the communication for 2 move or so in a ponder game >(without info). In your state diagram, there is only stop during ponder. So when >does the move come - after stop. This would not be good, I think, because >engines will want to think on in case of correctly predicted ponder move >(depending on used time etc. of course). Actually the UCI pondering looks very >elegant and easy, and probably will fit to over 90% of the engines. Seems that >this cannot be done with a more general ponder model. In this case really move >input would be needed during search. Perhaps even more, making the engine side >considerably more difficult. I agree here. If we really insist that no pondermove is played on the internal board while there is still a chance that it may need to be retracted, then the "move" and "go think" commands should be valid in ponder mode. Or maybe there could be a command of the form "ponderhit [g1f3]". Vas > >You could use both models. An engine that likes the normal pondering could send >bestmove pondermove. If only bestmove is sent, more general pondering is >requested. But does not look elegant. > >I don't understand the database discussion: if it has anything to do with the >engine/GUI communication I would strongly suggest to resist including such >things. > >The translation suggestion seemed not bad. But it would mean, that the GUI >author knows the engine already, and its internal parameters, so that he can do >the translation. Or the engine author has to deliver some (GUI-specific?) >translation data. How else could a new engine start. Therfore one should make >sure, that the default communicated options are understandable already, without >any translation process. What I mean is, instead of an option name PS (the >author might think this will be translated anyway, sa to pruning style) names >that speak for themselves should be used. Which of course gives the quoting >problem, when multi word names are allowed (which are easier). I personally do >not like those quoting mechanisms too much. But Tord is of course right, in >pointing out, that in the UCI spec it can be considered broken (although in >practice, it is not too bad). > >Recently I wanted to search for the two characters \" (with grep) inside PGN >files (Many PGN files have wrong tags with escaped quoting). I don't want to >remember what I had to type on the command line (could depend on the shell, >too). > >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.