USI2WB / UCI2WB release

[hgm]

I have now modified the USI2WB adapter such that by a minimal change of the sources (flipping a compiler switch) one can also generate a dumb UCI2WB adapter from it. Testing this UCI2WB with some well-behaved UCI engines allowed me to debug the ponder mode. So this now works both in UCI2WB and USI2WB (if the USI engine supports it, of course).

What is a dumb adapter, and why would anyone want to have one? (After all, we have Polyglot!)

This UCI2WB adapter is dumb, because it has no idea whatsoever about the game state, or in fact about the game rules. It just passes on the moves (and FENs) verbatim. So it does not even have to be aware of the size of the board, or the move encoding, as long as WB and the UCI engine understand each other's move format. (Which they do in Chess: long algebraic.)

The advantage is that you can use the adapter for any variant you want. In particular, you can use it for UCI Xiangqi engines (which seem to exist, next to UCCI Xiangqi engines). Of course you would have to make the adapter report to WB that it supports the variant, and the UCI2WB version I made says it plays variants normal and xiangqi. (The USI2WB of course says it plays variant shogi.)

A zip file with UCI2WB.exe and USI2WB.exe Windows binaries, plus the common source code, can be downloaded from:

http://home.hccnet.nl/h.g.muller/USI2WB.zip

[phhnguyen]

Hi Muller,

Very impressive with a such small UCI2WB!!! Thank you for your release.

Do you have any plan to integrate that program with WB - or make WB to support directly UCI?

I will definitely convert my engine to UCI one if WB supports directly that protocol.

Pham

[hgm]

Well, I have not decided on that yet. The design philosophy of supporting only a single universal protocol, and support all variant-specific protocols through adapters also has its merits. From the viewpoint of the user, the adapters can be practically invisible. (I.e., limited to specifying a /fUCI flag when invoking the engine, which he would have had to do anyway if the protocol driver had been integrated in WB.)

But let's not get ahead of ourselves. Although the UCI2WB adapter I posted could perfectly run Glaurung, it failed to run the Xiangqi engine Cyclone 2.1.1 which is supposed to be UCI). It turns out that Cyclone does use a non-standard form of UCI: it does not need the 'position' keyword and does not know 'startpos', but always needs a FEN to define the position. Furthermore, it acts non-compliantly when you do send it 'position': according to the UCI specs an engine should ignore whatever token is invalid, and parse the rest of the line. Cyclone, however, ignores the entire line when you preceed 'fen' with 'position' (as in standard UCI).

As Cyclone is the only UCI engine I have access too, I must assume that this is the Xiangqi dialect of UCI. (I don't see how XQ GUIs supporting UCI could work if different UCI engines need differen GUI->engine commands.) I thus fixed my UCI2WB adapter to use this dialect when WinBoard selects variant xiangqi.

Because I now use run-time switching between UCI dialects used for Chess and Xiangqi, I decided I might as well have run-time switching to USI as well. So there now is only a single UCI2WB.exe binary, to be used for all three variants. Unfortunately, to be used for USI, the adapter has to be told in advance, because it already has to know if it should send 'usi' or 'uci' to the engine during the initialization phase, before WB has told it which variant to play. So to be used as USI2WB, UCI2WB now has to be called with a flag argument -s (lower case, preceeding any other arguments!):

UCI2WB -s USI_ENGINE.exe ENGINE_FOLDER

For UCI the flag argument can be -c, or be left out. The new version, which is now tested on Glaurung 2.2 (Chess, w and wo pondering), Cyclone 2.1.1 (Xiangqi) and BlunderUSI (Shogi), can be downloaded from the same link:

http://home.hccnet.nl/h.g.muller/USI2WB.zip

There still are other 'known limitations' of this UCI2WB: UCI options with spaces in them are not handled correctly (USI does not allow this). Analysis mode is not implemented, and mlti-PV only works by accident (but quite poorly). The focus was at engine-engine games, and I only payed attention to that. But it means the code is not yet up to the quality standards for WinBoard.

In fact all of UCI is not really up to WB standards. To be considered acceptable for implementation in WB, it would be necessary to tighten and extend the specs. The current specs do not seem to be clear enough in what an engine should do when it is confronted with a position where it has no moves. (Or, due to a bug, thinks it has no moves.) At least every engine I have looked at so far does this differently, and none of them does it in the way I think the original SMK specs prescribe it. The ways for the engine to report checkmate and stalemate should be anchored explicitly in the specs, rather than only implied (as they are now). The protocol should be extended to allow offering and accepting draws. There should be a standard way for the engine to resign. There must be a standard way for the engine to report inconsistent input (alleged illegal moves, positions it cannot handle). Without all that, the protocol would be too crappy to even consider it...

[hgm]

I posted a new version of UCI2WB on said link.

This version should handle pondering correctly, sending time parameters with the 'go ponder' comment, and movestogo according to the future move for which it is pondering.

It also supports analysis mode.

I tested this version with pondering succesfully on Glaurung 2.2 and Cyclone 2.1.1.

What is the UCI prescription for pondering when an engine does not give a ponder move with its 'bestmove'? Should the GUI not set the engine pondering at all, or would the engine expect me to set it pondering on the opponent position? In the latter case, would it expect me to do anything special in case of a 'hit' (i.e. the bestmove from the aborted ponder search being equal to the move played by the opponent), or would it not care if it was a hit ?

[Matthias Gemuh]

What is the UCI prescription for pondering when an engine does not give a ponder move with its 'bestmove'?

Pondering not supported or not desired.

[hgm]

OK, that is easy. It already works!

What if it would send me:

bestmove e2e4 ponder 0000

? Is that a valid way to request pondering the current position? I guess not, because according to specs this would mean it want you to ponder the null move, which changes the side to move. So you would be pondering for the wrong side. Currentlty I would just feed the 0000 back to the engine without looking at it, in the next position command. No idea how the engine is supposed to react to that. But at least it will be a guaranteed ponder miss.

[Matthias Gemuh]

What if it would send me:

bestmove e2e4 ponder 0000

... Currentlty I would just feed the 0000 back to the engine without looking at it, in the next position command.

If you can determine that 0000 is not a valid move, don't permit pondering.

[hgm]

Thesting for 0000 is of course easy. I already do that in the bestmove field, to detect if the engine is checkmated or stalemated.

But I actually never encountered an engine yet that is compliant to the UCI specs! Glaurung prints "null", Fruit prints "(none)", BlunderUSI prints "resign"...

[liuzy]

Thesting for 0000 is of course easy. I already do that in the bestmove field, to detect if the engine is checkmated or stalemated.

But I actually never encountered an engine yet that is compliant to the UCI specs! Glaurung prints "null", Fruit prints "(none)", BlunderUSI prints "resign"...

I'm sad to ensure that this UCI2WB for XQ is only OLD-CYCLONE standard, even new cyclone supports UCI in a more standard way.
The standard position setting command is "position fen ****" other than "fen ****".
And the moves along with the fen is also very strange.

[hgm]

Well, the Cyclone I had was Deep Cyclone 2.1.1, and when you include "position" there, it ignores the moves completely. It also does not know "startpos". I agree that is non-standard UCI, and it took me actually a lot of trouble to find out that this was the problem...

So you are saying that there are other UCI XQ engines that support a more standard version of UCI, and for which this adapter does not work? If so, which are those, and where can I get them?

What is strange in the moves that go along with the FEN?

It would be easy enough to switch only to the UCI dialect used by Cyclone 2.1.1 on command of a flag argument, like -s now switches to USI. Currently I switch to this dialect as soon at variant xiangqi is selected by WinBoard.