Polyglot question

[H.G.Muller]

This is a question to Michel:

By now you must know Polyglot pretty well. How difficult would it be to convert Polyglot to an adapter for Shogi? Would that just be a matter of changing the board and move generator, or would it involve much more?

Or would it be simpler to write something from scratch, if the only requirement is that it converts WB protocol to UCI / USI (so no book stuff or legality testing, just passing the moves verbatim, and perhaps taking care of setting the engine pondering)?

[Michel]

Well I have never touched the chess logic in polyglot (which is copied from Fruit AFAICS).
The chess logic is separate from the protocol logic, but represents a fair amount of code
spread over approximately the following files

attack.c (used?) move.c pgn.c
board.c move_do.c piece.c square.c
fen.c move_gen.c
game.c move_legal.c
colour.c hash.c san.c

Since USI is just a minor extension of UCI I guess the real issue is variant support in PG.
It is of course doable but represents a fair amount of work and there is the issue
of the huge code duplication with xboard. Ideally the variants should be separate
libraries which can be shared between GUI's and adapters (that is how I would approach it).

But let me say immediately that I currently have no time to work on such a major project
but if you want to make a USI version of PG then you are of course free to do so.

You suggested once that PG should not contain any chess logic at all. This is true to
some extent but in that case the xboard engine emulated by PG would look
rather different from a genuine xboard engine.

Things that come to mind are

(1) It would not recognize illegal moves from the GUI.
(2) It would have no SAN support.
(3) It could not use its own book (except if the UCI engine supports it).
(4) It could not claim draw for the 50 move rule, 3 fold repetition, stalemate etc....

Of course none of these are essential as xboard will take care of it. It just makes the xboard engine look less professional.

[H.G.Muller]

Don't worry, I am not trying to dump this on you. I just wanted some pointers that set me in the right direction for doing this.

About your point (1): don't UCI engines somehow complain if you feed them an illegal move, amongst the sequence of moves needed to setup the current position? If they do, I would simply relay that to the GUI. (Not that I plan to allow WB to feed them any illegal moves, of course.)

The other points do not worry me much. I guess Shogi engines typically do manage their own books in their own formats. I don't think USI suggested a standardiztion for books. Most variants would not have any opening theory at all anyway. And if all else fails, there is always the GUI book, which has the same format as any adapter book would have had. Usage of SAN is not default in XBoard protocol, and not even recommended. Result-claiming by engines could even be argued to be undesirable.

But even if it would look 'amateurish', I am looking at this purely from a pragmatic point of view. I want to create the possibility to play my own (WB) Shogi engine against USI opponents, with the least possible amount of effort. The only requirement is that they play automatically from the initial position, and that I can record the correct game result.

[Michel]

About your point (1): don't UCI engines somehow complain if you feed them an illegal move, amongst the sequence of moves needed to setup the current position? If they do, I would simply relay that to the GUI. (Not that I plan to allow WB to feed them any illegal moves, of course.)

No. UCI engines just ignore silently everything which is not part of the protocol (including illegal moves).

Usage of SAN is not default in XBoard protocol, and not even recommended.

I know but UCI pv's do not look very nice. For one thing they don't show the piece that's moving. Normally it is the GUI's job to translate these
into human readable PV's.

But even if it would look 'amateurish', I am looking at this purely from a pragmatic point of view. I want to create the possibility to play my own (WB) Shogi engine against USI opponents, with the least possible amount of effort. The only requirement is that they play automatically from the initial position, and that I can record the correct game result.

Ok. In that case making all chess related commands noops will probably do the job (at least approximately).

[H.G.Muller]

No. UCI engines just ignore silently everything which is not part of the protocol (including illegal moves).

Well, then UCI engines do look amateurish by definition, and it is only justice that the adapter passes on this impression, properly translated into WB protocol...

I must admit that my native WB Xiangqi engine HaQiKi D also does not do any form of legality checking, but blindly copies the from-square tot the to-square, (obliterating anything that might be n the latter, be it friend or foe).

I know but UCI pv's do not look very nice. For one thing they don't show the piece that's moving. Normally it is the GUI's job to translate these
into human readable PV's.

True. But this is just as true for thinking output of native WB engines, so the GUI should do it (as you say), not the adapter. I actually considered having XBoard do this (optionally). Most of the code to do this is in fact already there, as part of the interactive PV walking. This generates SAN moves in addition to all the boards, so they can be displayed together when the user scrolls through the PV. I could call this LoadPV() routine on reception of any PV, rather than just when the user presses the corresponding mouse button, and then replace the original PV by the SAN moves.

It might eat CPU time, though, for generating SAN moves in WB is rather inefficient. (It basically involves a completely un-pruned 2-ply search for each move.)

I am slowly drifting towards the opinion that human-readability of the PV is only a poor-man's solution anyway: when I want to know what the engine is thinking about, I just have the GUI play it out for me on the board.

[Michel]

Well, then UCI engines do look amateurish by definition,

Well they just do as they are told. In the UCI world the GUI does everything.

I must admit that my native WB Xiangqi engine HaQiKi D also does not do any form of legality checking, but blindly copies the from-square tot the to-square, (obliterating anything that might be n the latter, be it friend or foe).

Of course a UCI engine will (should) not crash when fed illegal moves. It will just ignore them.

I am slowly drifting towards the opinion that human-readability of the PV is only a poor-man's solution anyway: when I want to know what the engine is thinking about, I just have the GUI play it out for me on the board.

It seems to me you are slowly drifting towards the UCI way of doing things...

[H.G.Muller]

Of course a UCI engine will (should) not crash when fed illegal moves. It will just ignore them.

In the end that amounts to he same thing, because the engine will respond with a move, not with a position. So it will likely generate an illegal move, because it is thinking from a different position, but the GUI has no clue what position then engine is thinking from. So there is no way to correct the situation, and the only thing the GUI can do is restart the engine, in the hope that whatever made it to malfunction has gone away.

It seems to make no sense to make it a protocol requirement that the moves are legal. Wouldn't the requirement that the reply is legal destroy the statelessness of the protocol? It would be much more productive to simply have the engine perform the moves it is told to perform, legal or not.

It seems to me you are slowly drifting towards the UCI way of doing things...

What makes you say that? Surely the feature to step through the PV has nothing to do with the protocol used to transfer the PV between engine and GUI? Displaying positions is by definition a GUI task, which the engines should never be involved in.

[Michel]

What makes you say that? Surely the feature to step through the PV has nothing to do with the protocol used to transfer the PV between engine and GUI? Displaying positions is by definition a GUI task, which the engines should never be involved in.

In the xboard world the presentation of the PV has always been considered the engine's task (the very latest
publicly released xboard versions still do it that way).
Engines compete in trying to present the nicest looking pv to the user (with smilies and comments and all that) and of course
they all use a slightly different format, making it difficult to parse.

The UCI protocol by contrast opts for a bare bones format but which is strictly specified and
trivial to parse by the GUI.

What you are basically saying (but you will deny it) is that the UCI protocol took the better
approach in this case.

[H.G.Muller]

In fact I always have abhorred these SAN PVs. None of my engines actually produces SAN. IMO engines that do are simply abusing the freedom that WB protocol allows them.

There have been maany requests to standardize the PV field in WB thinking output. Tim Mann has always been adamant that in that case long algebraic should become the standard. And I fully agree with him.

[Michel]

IMO engines that do are simply abusing the freedom that WB protocol allows them.

No. They are simply using the freedom that the WB protocol allows them to produce the nicest looking PV (at least in their own opinion)

The WB protocol has always been about empowering the engine (you said this many times yourself).

[H.G.Muller]

The engine should play Chess, yes. But is should not have any say in how the display looks. We don't want engines to define bitmaps for the pieces, or the size, color and texture of the chess board, or the order of items on the menu bar, or the fonts they are written in. Those are between user and GUI to decide.

IMO the display format for the PV is something that belongs in the same category. Some people prefer SAN, some prefer long algebraic. The GUI should allow them to choose what they prefer, independently of what the engine does (SAN / long-algebraic / raw). Yust like they can choose western or oriental pieces for playing Xiangqi.

How exactly the engine pumps the data to the GUI should not be a user's concern.

[Dann Corbit]

Don't worry, I am not trying to dump this on you. I just wanted some pointers that set me in the right direction for doing this.

About your point (1): don't UCI engines somehow complain if you feed them an illegal move, amongst the sequence of moves needed to setup the current position? If they do, I would simply relay that to the GUI. (Not that I plan to allow WB to feed them any illegal moves, of course.)

The other points do not worry me much. I guess Shogi engines typically do manage their own books in their own formats. I don't think USI suggested a standardiztion for books. Most variants would not have any opening theory at all anyway. And if all else fails, there is always the GUI book, which has the same format as any adapter book would have had. Usage of SAN is not default in XBoard protocol, and not even recommended. Result-claiming by engines could even be argued to be undesirable.

But even if it would look 'amateurish', I am looking at this purely from a pragmatic point of view. I want to create the possibility to play my own (WB) Shogi engine against USI opponents, with the least possible amount of effort. The only requirement is that they play automatically from the initial position, and that I can record the correct game result.

I have lots of Shogi code if any of it can be of help to you.

[Michel]

Ok now you have argued that the features which distinguish an xboard
engine from a UCI engine are irrelevant or even undesirable.

So we must conclude that it is completely irrelevant if and engine implements
the xboard protocol or UCI protocol, not?

[H.G.Muller]

To the user, mostly so. (Of course the user will still be exposed to the minor inconvenience that UCI does not support draw offers.)

To the engine or GUI programmer: far from it. From what you have told, it seems that a UCI engine cannot even give error messages that would be helpful for debugging... And a GUI author will have to do a lot of pampering to create the impression for the user that the UCI engine actually works.

[Michel]

To the engine or GUI programmer: far from it.

Well for the engine programmer's point of view UCI seems a lot easier. UCI has only a few commands and there is no need to maintain game state. There is no need to explicitly implement ponder or analysis. Nor is it necessary implement "advanced" commands like undo (which make life easier for the user) as the GUI will take care of.

For the GUI I see little difference. The GUI needs to track the state of the game anyway. So the amount of work required
to manage an xboard engine or UCI engine is the same (one can can argue that the lack of debug info is a slight inconvenience, but the GUI should not send illegal moves to the engine anyway, and the engine is free to send debug info through info strings of course).

To be honest I find this UCI vs xboard arguing silly but I do not agree that somehow the xboard protocol is vastly superior.

[H.G.Muller]

Obviously moving tasks from the engine to the GUI makes things easier for the engine programmer. One could go even much further in that than UCI does. One could for instance reduce the engine to a DLL for the evaluation function, and leaving the search entirely to the GUI. (Possibly allowing the 'engine' to set some of the search parameters, such as which extensions to switch on or off.)

Still easier would be to also move the evaluation to the GUI, and reduce the engine to a DLL that is called by the GUI to set the evaluation parameters. Why not build Robbolito into the GUI? That would really save engine authors a lot of work.

Some people (in particular tournament organizers) think that minimizing the work to be done by the engine programmer is not really an important cause, or in fact a very undesirable one. They call it cloning. I think it is a very legitimate question if an engine should be allowed to play through the GUI book on a tournament like WCCC (or use Nalimov probing code, or use the Ribbolito search...). You would be using code for move-making decisions that is not your own.

[H.G.Muller]

Would it be correct to state that UCI engines actually do claim mates through the pv info line?

If I understood the specs correctly such a line obligatory preceeds the 'bestmove' command, and must contain all info next to the PV, including the score. Presmaby this would be

info score mate 1 ...

whenever it performs a move that checkmates. A 'dumb' adapter could flag that, and issue the result claim after the next move is received and relayed.

What is a UCI engine supposed to do if you feed it a position where it is checkmated, and set it thinking? Would it answer with info score mate 0 ...? What would it have to do for bestmove? I noticed some USI engines do emit a bestmove resign (even when not mated). Is this a non-compliant frivolity? What is the compliant way to handle this? If there is no special command for it, must they issue an illegal move? Can it be an obviously illegal move, like a1a1?

[edit] Glaurung 2.2 apparently prints bestmove (none) when it is checkmated or stalemated.

[Michel]

Would it be correct to state that UCI engines actually do claim mates through the pv info line?

You seem to be right. The specs do say this. Polyglot recognizes the mate key word and replaces it by an appropriate mate score.

What is a UCI engine supposed to do if you feed it a position where it is checkmated, and set it thinking? Would it answer with info score mate 0 ...?

In principle the GUI is not supposed to do this so the effect would be undefined. Fruit seems to return bestmove a1a1 though (which is internally coded
as "0000").

AFAICS there is no standard way for an UCI engine to resign. Of course the idea is again that adjudication will be done by the GUI.

EDIT

This is Robbolito:

RobboLito VERSION k-m��
uci
id name RobboLito version ci
id author Yakov Petrovich Golyadkin, Igor Igorovoich Igoronov, Roberto Pescatore
id copyright Yakov Petrovich Golyadkin (all), 92th year from Revolution, PUBLICDOMAIN (workers)
id dedication To Vladimir Ilyich
option name TranspositionalTabularSizing (Zobrist) in MegaBytes. Note: Only dyadic powers suffice terminally! type spin min 1 max 16384 default 32
uciok
position startpos moves f2f3 e7e5 g2g4 d8h4
go
info time 0 nodes 0 nps 0 score mate 0 depth 0 seldepth 1 pv NULL
bestmove NULL

And Rybka.

uci
id name Rybka 2.2n2 mp
id author Vasik Rajlich
option name Hash type spin min 2 max 4096 default 32
...
option name Emergency Time Buffer type combo default Medium var Small var Medium var Large
uciok
position startpos moves f2f3 e7e5 g2g4 d8h4
go
info depth 2
info depth 2 time 1 nodes 18 nps 18432
info depth 3
info depth 3 time 1 nodes 18 nps 18432
info depth 4
info depth 4 time 2 nodes 18 nps 9216
info depth 5
info depth 5 time 2 nodes 18 nps 9216
info depth 1 score cp 0 nodes 18 pv a1a1
info time 2 nodes 18 nps 576
bestmove a1a1

[H.G.Muller]

Well, for Chess, of course, it usually is. But it is a pretty bad idea nevertheless, because is makes the protocol incapable of handling variants that the GUI does not know. (Plus, of course, that it makes it impossible for the engine to resign. A GUI might be ble to recognize mate, but is can never know when an engine wants to resign.) The reason why it becomes an issue now is that in WB mate detection does not work yet in drop games. Of course in due time I will fix this, but it is not really trivial. (Not every piece you might have in the holdings can be dropped everywhere; in Crazyhouse Pawns cannot be dropped on first and last rank. In Shogi you cannot drop Pawns on a file that already contains one, and not drop them with checkmate, and you cannot drop pieces on squares where they can never have moves, like last-rank Pawns.)

It seems a pretty save assumption that an engine confronted with a position where it is checkmated would respond with a 'mate 0' score. But in a stalemate position it is more likely to produce a 'cp 0' score, which could mean anything. So for stalemates you would have to depend on the move.

What it would produce for a move will be more implementation-dependent. A move with fromSqr == toSqr would be illegal in any variant I can imagine, and actually quite likely to be given in this case if no special handling is programmed. So I could at least recognize that, and then let the score decide if it was stalemte or checkmate.

Btw, I looked at the UCI protocol specs, and it says somewhere: "A nullmove from the Engine to the GUI should be send as 0000." And wouldn't it seem logical that when you have no legal moves, (or for other reasons want to express a refusal to move), you would have to send a null move as bestmove? Why else would an engine ever want to send null moves to the GUI? PVs cannot contain null moves, can they?

Another question: If an engine does not provide a ponder move with its bestmove, and ponder is on... Should the GUI then set the engine pondering the position with the opponent to move?

[Michel]

it usually is. But it is a pretty bad idea nevertheless, because is makes the protocol incapable of handling variants that the GUI does not know.

Well the main point of the xboard protocol is that a GUI without any chess knowledge can use it. My FICS client icsdroneng for example has zero chess knowledge.
I rely on the engine to claim results and to produce human readable PV's.

The UCI protocol on the other hand is designed for a GUI with chess knowledge.

It is just a trade off.

Btw, I looked at the UCI protocol specs, and it says somewhere: "A nullmove from the Engine to the GUI should be send as 0000." And wouldn't it seem logical that when you have no legal moves, (or for other reasons want to express a refusal to move), you would have to send a null move as bestmove? Why else would an engine ever want to send null moves to the GUI? PVs cannot contain null moves, can they?

I have no idea what is meant by that. I thought too that it was meant for cases in which the engine does not have a bestmove to return (like a mate solver that does not find a mate).
However it seems other GUI's do not recognize it.

Another question: If an engine does not provide a ponder move with its bestmove, and ponder is on... Should the GUI then set the engine pondering the position with the opponent to move?

I think the GUI is free to do what it wants. Just pondering on the position seems logical. But why would the engine not supply a ponder move?