UCI Engines without the graphical interface

[mephisto]

Hi Gents
I think that I am going to now use the excellent Mephisto MM5 ROM using the MESS emulator. Many thanks for showing an interest in my post.
Regards
Bryan

[Onno Garms]

maybe

Code: Select all

position moves e7e5

is not exactly valid?

You are right, that is not valid UCI. Valid UCI would be
position startpos moves <whatever>
or
position fen <whatever> moves <whatever>

But as "position moves e7e5" is not valid UCI, no GUI will send it and I can do what I want on that command.

My view on the position command (mirrored in my implementation) is that the "position" command merely says that commands to modify the internal board follow. There are three commands of this kind:
1. startpos (0 parameters)
2. fen (1 parameter)
3. moves (0 to n parameters)

UCI says that there must be exactly one of 1 and 2, followed by 3. I relaxed that to "zero or one of 1 and 2".

That's one of the advantages of UCI: The engine can enhance it without breaking compatibilities with GUIs, because uninformed GUIs will simly not use the enhancement. The GUI can also use own enhancements because the protocol requires the engine to ignore unknown commands.

I added the relaxation to simplify debugging the engine from the command line. It definitely paid off.

[Onno Garms]

how much time is lost with UCI engines parsing unecessarily long input?

I don't think that that is a bottleneck.

there is an alternative to loading the startposition, and making each and every move until the current position is reached:
if the UCI engine has the ability to remember the game position (which almost all do) , then it simply has to parse to the end of the command line, and capture and make the last move indicated...

Sounds like saving time in the wrong place to me.

Note that you would also have to remember the last command line and check the new against it. They might be different, e.g. after taking moves back.

The reason that my engine remembers the board is mainly to simplify debugging, but also because I leave parsing the position string to the base class and wanted seperate virtual functions in it for startpos, fen, and moves. Faster board setup was definitely not a motivation.

[michiguel]

maybe

Code: Select all

position moves e7e5

is not exactly valid?

You are right, that is not valid UCI. Valid UCI would be
position startpos moves <whatever>
or
position fen <whatever> moves <whatever>

But as "position moves e7e5" is not valid UCI, no GUI will send it and I can do what I want on that command.

My view on the position command (mirrored in my implementation) is that the "position" command merely says that commands to modify the internal board follow. There are three commands of this kind:
1. startpos (0 parameters)
2. fen (1 parameter)
3. moves (0 to n parameters)

UCI says that there must be exactly one of 1 and 2, followed by 3. I relaxed that to "zero or one of 1 and 2".

That's one of the advantages of UCI: The engine can enhance it without breaking compatibilities with GUIs, because uninformed GUIs will simly not use the enhancement. The GUI can also use own enhancements because the protocol requires the engine to ignore unknown commands.

I added the relaxation to simplify debugging the engine from the command line. It definitely paid off.

IMHO, that is no advantage.. You are just using a set of commands that are not UCI. In fact, you are forced to use that workaround because UCI is stateless by design and you want a command that depends on the state.

Miguel

[Aleks Peshkov]

Engine should keep the state between "position" and "go" commands.
Most engines return to root position from search recursion automatically.

I see no trouble to keep state between "position" and next "position" command.

[Onno Garms]

UCI is stateless by design and you want a command that depends on the state.

If UCI would be stateless, OK. But UCI keeps state between "position" and "go" so UCI is not stateless anyway.

[Don]

The UCI way is not a flaw in the protocol, it is a good way to do it. It makes no assumptions about state, and I think that is the more technically correct way to handle this.

This also does not prevent the program from doing it's own thing internally, but technically you should not assume the last position is part of the same game.

I'm not being critical of the xboard protocol, each does the job well, but I do prefer the UCI way.