Author: Dann Corbit
Date: 16:05:44 08/21/02
Go up one level in this thread
On August 21, 2002 at 18:56:29, Dieter Buerssner wrote:
>On August 21, 2002 at 16:17:22, Dann Corbit wrote:
>
>>On August 21, 2002 at 15:52:25, Dieter Buerssner wrote:
>>
>>>I fear, lex/yacc are not suitable for this task. Without thinking about it too
>>>deep, it seems one would need to design the engine around the protocol.
>>
>>This already happens, or the engine is bent to comply to it, if the protocol was
>>unknown when the design began.
>
>I don't agree, here. I believe, the main thing is the search engine, and then
>you glue it up with the interface. I have no idea, how a yacc grammar could do
>this (it would need to do things deep inside the search as well as in some outer
>controlling loop).
The protocol and parser I suggest does not solve that problem. It solves the
problem of:
Someone sent me a string. What does it mean?
Answer from parser:
Perform command x with parameters a, b, c
So parser calls:
x(a,b,c);
You still have to write the callback. And your engine has to know how to handle
the callback.
It is still up to you to implement the action.
>>>I think for an engine-GUI protocol, one idea of UCI is much better: Minimize the
>>>commands allowed during search. Under UCI, I believe only stop and ponderhit is
>>>possible. Under WB many things are possible.
>>
>>I think if a separate thread reads commands and puts them into a queue, some of
>>the difficulty goes away.
>
>I think not. The problem is not detecting the commands, and beeing able to
>process them. The problem is that many commands are possible at all sort of
>times, and it is not allways really clear what to do.
Then I think that the protocol is underspecified. Just a list of commands
without concrete directions on exactly what these commands must mean and how
they should be handled indicates incompleteness.
>Perhaps it is with very
>careful reading of the protocol. I would guess, that more than half of the WB
>engines would have serious troubles for some not too typical things (say undoing
>moves, aborting a game during search/ponder, ...) with the slighly different
>implementations of the WB protocol in different GUIs.
That indicates that either:
1. The protocol is ambiguous
Or
2. The protocol is too complex
Or
3. Both of the above.
The solution is to disambiguate the protocol and also (possibly) to simplify it.
>> In particular, handicap time controls where one side has {e.g.} G/30 and the
>>other G/57 would be useful for hardware matching contests.
>
>This is possible under UCI.
>
>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.