Author: Lance Perkins
Date: 10:17:54 03/10/05
Go up one level in this thread
Instead of saying 'move list' I should have said 'board state'. All engines know
what the current board state is after making a move. They don't need to be told
and retold what series of moves are needed to get there again. Even your engine
knows what the board state is after you've computed your next move. To trash
that current board state does not buy you anything.
Lest's compare:
In xboard, after making a move, the engine (knowing "current" board state) now
waits for the next "move".
In UCI, after making a move, the engine (knowing the "initial" board state, goes
to the initial board state) now waits for the next "moves".
Is the UCI a 'better' design? I don't think so. And I'm not saying this because
I am comparing it to xboard. Rather, its just bad from a protocol design
perspective.
The old HTTP protocol spec is a simple request-reply design. Totally
stateles. But the persona of the browser is not so. Browsers and users typically
request many items from the same site. So instead of throwing away the
connection state, they added the 'reuse' mode in the HTTP protocol. You don't
need to disconnect and then reconnect - you already know you are connected -
just make another request.
Isn't the old spec enough to cover both scenarios (those making a single request
and those making multiple requests)? Yes it is enough. For the multiple
requests, they just have to reconnect for every request.
So why do we need to update the HTTP protocol? Because the 'core' scenario is
not stateless. In the same way, ICS and xboard works because in the core
scenario, engines are not stateless.
---
On March 10, 2005 at 05:51:30, Tord Romstad wrote:
>On March 10, 2005 at 04:33:59, Lance Perkins wrote:
>
>>Can you name an engine that does not keep track of the move list, and that it
>>needs to be told what the move list is for every move?
>
>Of course I can. My own engine does not keep track of the move list, and it
>needs to be told the move list for every move. It makes life a lot easier
>to me. The engine becomes a simple program which receives a position and
>a command to start searching, and nothing move. I don't need any data
>structures except those I use in the search. I don't need a move history.
>There is no need to write code to undo moves, or to handle several different
>modes (normal play, analyze, force, etc.).
>
>My code becomes much cleaner and simpler when I can keep my engine modeless
>and stateless. Of course I would be able to cope with the complexities of
>the xboard protocol if I really needed to (my old engine supported both
>protocols), but I am very happy that I can now avoid it (thanks to
>Fabien's excellent PolyGlot adapter).
>
>>The engine know a lot more - like, how to score book moves (and the scoring
>>varies between engines) and learn from it.
>
>I'm not sure I understand what you mean here.
>
>>This UCI issue is simple - its a bad design.
>>
>>In contemporary software design, we think of 'personas' and 'scenarios'. In this
>>regard, UCI has missed the persona of the engine, and missed the scenario of
>>exchanging moves - the most common scenario ('core' scenario).
>>
>>So how does xboard address the other scenario where one must really set the
>>board state to some position? You just send a 'setboard' command.
>
>I find it very convenient that setting up positions and exchanging moves
>can be done with a single command rather than two different commands.
>It means less work and less code in my engine.
>
>>Sure it is cheap to write code to work around it, but its still a bad protocol
>>design.
>
>I think this depends on where you are coming from. If you start with an
>xboard engine and try to add UCI support, I can understand your views. For
>an engine which is designed with the UCI protocol in mind from the outset,
>the situation is rather different. For me it is the xboard protocol which
>would require cheap (but ugly) code to work around it.
>
>The UCI protocol is not perfect, but in my opinion sending the move list
>with every move is not one of the weaknesses. I prefer not having to keep
>track of the moves in my engine, and to unify exchange of moves and setting
>up positions to a single scenario.
>
>Tord
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.