Crafty UCI version

[Ferdy]

Why doesn't it work under WB2UCI?

Fritz GUI's Deep Position Analysis (DPA) would work for engines that supports multipv. Crafty does not implement multipv so far.

Deuterium WB has multipv support, and using WB2UCI still does not work because my WB implementation is

Code: Select all

feature option="multiPV -spin 1 1 300"

I revised this to MultiPV instead of multiPV. But then WB2UCI will send only

Code: Select all

MultiPV n

to deuterium but it expects

Code: Select all

option MultiPV=n

So I revised again to accept MultiPV n, this command is now recognized.
But still there is a problem, sample run at MultiPV 2.

Code: Select all

5.444: S> 4     0      1        731 g1f3 g8f6 b1c3 b8c6
5.444: C< info depth 4 score cp 0 time 10 nodes 731 nps 73100 pv g1f3 g8f6 b1c3 b8c6
5.444: S> 4     0      1        829 b1c3 g8f6 g1f3 b8c6
5.444: C< info depth 4 score cp 0 time 10 nodes 829 nps 82900 pv b1c3 g8f6 g1f3 b8c6
5.444: S> 5    27      1       1032 g1f3 g8f6 b1c3 b8c6 d2d3
5.444: C< info depth 5 score cp 27 time 10 nodes 1032 nps 103200 pv g1f3 g8f6 b1c3 b8c6 d2d3
5.444: S> 5    27      1       1175 b1c3 g8f6 g1f3 b8c6 d2d3
5.444: C< info depth 5 score cp 27 time 10 nodes 1175 nps 117500 pv b1c3 g8f6 g1f3 b8c6 d2d3
5.444: S> 6     0      1       2680 g1f3 g8f6 b1c3 b8c6 d2d3 d7d6
5.444: C< info depth 6 score cp 0 time 10 nodes 2680 nps 268000 pv g1f3 g8f6 b1c3 b8c6 d2d3 d7d6
5.444: S> 6     0      1       3019 b1c3 g8f6 g1f3 b8c6 d2d3 d7d6
5.444: C< info depth 6 score cp 0 time 10 nodes 3019 nps 301900 pv b1c3 g8f6 g1f3 b8c6 d2d3 d7d6

WB2UCI does not recognize that Deuterium is in multipv mode and that is sending

Code: Select all

depth score time ...

twice with different pv with same depth.
What is missing here is the key word multipv n ... in the translation.

Code: Select all

5.444: C< info depth 6 score cp 0 time 10 nodes 3019 nps 301900 pv b1c3 g8f6 g1f3 b8c6 d2d3 d7d6

It should have been,

Code: Select all

5.444: C< info depth 6 multipv 1 score cp 0 time 10 nodes 3019 nps 301900 pv b1c3 g8f6 g1f3 b8c6 d2d3 d7d6

But how could WB2UCI figure out which is multipv 1, multipv 2? Is there a standard in CECP to handle multipv?

CECP

Code: Select all

ply score time nodes pv
Where:

ply	Integer giving current search depth.
score	Integer giving current evaluation in centipawns.
time	Current search time in centiseconds (ex:1028 = 10.28 seconds).
nodes	Nodes searched.
pv	Freeform text giving current "best" line. You can continue the pv onto another line if you start each continuation line with at least four space characters.
Example:

  9 156 1084 48000 Nf3 Nc6 Nc3 Nf6
Meaning:

9 ply, score=1.56, time = 10.84 seconds, nodes=48000, PV = "Nf3 Nc6 Nc3 Nf6"

So WB engines using WB2UCI adapter running on Fritz gui on DPA will not work because there is no multipv key word in the output sent by WB2UCI to Fritz interface.

[hgm]

Fritz GUI's Deep Position Analysis (DPA) would work for engines that supports multipv. Crafty does not implement multipv so far.

That is in any case a Crafty problem, which won't get away by making it UCI. Engines don't magically require new features when you change their communication protocol.

....
So WB engines using WB2UCI adapter running on Fritz gui on DPA will not work because there is no multipv key word in the output sent by WB2UCI to Fritz interface.

It sounds like WB2UCI is defective in several ways. I have no idea why it would leave out the '=' sign when sending an option value; this is always wrong in WB protocol.

As to the numbering of the PVs: there is no standard for that in WB protocol, and I think that also in UCI the numbering is arbitrary. WB2UCI can just slam different multipv N qualifiers on the different lines with the same depth. It can know it is in multi-PV mode; the UCI interface will have told it that. If it wants to be clever it can sort the lines by score, and number them accordingly. But it can also order them by order of arrival, letting the engine implicitly decide on the numbering.

[Werewolf]

Why doesn't it work under WB2UCI?

For some strange reason the evaluation always used to be inverted, among other problems.

[hgm]

IIRC this is also a Crafty-specific problem. When you run Crafty in WinBoard/XBoard, it also reports inverted scores, compared to other engines. Again, this is not something that would be solved by changing to another protocol, but by making the engine compliant to whatever protocol it is using.

WinBoard and Polyglot have work-around options to cure the most common non-compliancies in engines (such as wrong sign of the score reporting). Of course WB2UCI could do something similar.

[Marek Soszynski]

IIRC this is also a Crafty-specific problem. When you run Crafty in WinBoard/XBoard, it also reports inverted scores, compared to other engines. Again, this is not something that would be solved by changing to another protocol, but by making the engine compliant to whatever protocol it is using.

When I wondered whether "someone out there [could] fork Crafty and produce a UCI version" I didn't mean a broken or eccentric UCI version. I obviously meant a useable UCI version.

[hgm]

Well, a first and necessary step would then be to make a 'compliant and usable' WB version. (E.g. implement multi-PV support.) And as most problems that bother people would have gone away after that, it would be rather pointless to make a UCI version, which would only be a step backwards, and partly wreck the engine again. (No draw offering/acceptance, etc.)

My point is that what you propose is solving problems where they do not ly, which is always a bad idea. Many GUIs already directly support (compliant) WB engines, and if the few GUIs that now don't would be fixed to support it, the problem would have been solved without the need to convert every individual engine. If there would be a single full-featured WB-to-UCI adapter similar in quality to Polyglot, any compliant WB engine could run under any UCI-only GUI almost transparently. And the adapter could even implement work-around options for simple non-compliancies that can be solved outside the engine (such as flipping of the score sign).

So the best solution to the problems you experiencing is make a full-featured WB-to-UCI adapter. Which then solves the problems for all GUIs and engines at once. And it would probably be less work than converting a single WB engine to UCI!

[Evert]

What "control" does a GUI using the UCI protocol take away that CECP does not?

I'm not claiming I have fully grasped the specs yet, but the following things affect server play that I think are hard in UCI:
1. Knowing the identity of the opponent. (I use this in the book move selection.)
2. Knowing the rating difference with the opponent. (I use this for resign and draw offers/accept. And I plan to use it in book move selection as Black.)
3. Knowing if the opponent has offered draw, so I can decide to accept it or not, depending on my conditions based on parameters such as ratings, time control and clocks.
4. Being able to offer draw. For this I want to know the clocks, the time controls, and the ratings.
5. Being able to resign on my own conditions. For example, never when the opponent is in time trouble, in fast games without increment, when there is a "technical win", or when the opponent is much lower rated.
6. Being able to claim draw only after 51 moves, instead of 50. Because quite a few online engines mess up here and throw a piece on move 50 and forget to claim draw. I want to win those games.
7. Knowing when the game has ended, so I can trigger post-processing.

I realise all such things don't impact people using the engine for analysis or playing themselves or running basement tournaments. It is mostly for online play, and I wouldn't mind to migrate this all into icsdrone for example.

Ah, yes, good point: UCI doesn't offer any knowledge on the opponent (at least not in a standard way), or allow draw offers/resignations (again, in a standard way). I hadn't considered that because I don't play on servers and usually leave resign/draw offer disabled in the engine options. I wonder if I remembered to force them to "off" when switching to UCI mode...

[Evert]

IIRC this is also a Crafty-specific problem. When you run Crafty in WinBoard/XBoard, it also reports inverted scores, compared to other engines. Again, this is not something that would be solved by changing to another protocol, but by making the engine compliant to whatever protocol it is using.

When I wondered whether "someone out there [could] fork Crafty and produce a UCI version" I didn't mean a broken or eccentric UCI version. I obviously meant a useable UCI version.

You're (deliberately?) missing the point: the "problem" with Crafty is that it has some idiosyncrasies (always report score from white POV rather than engine POV, no or few configurable options), not that it doesn't support UCI.

[Marek Soszynski]

IIRC this is also a Crafty-specific problem. When you run Crafty in WinBoard/XBoard, it also reports inverted scores, compared to other engines. Again, this is not something that would be solved by changing to another protocol, but by making the engine compliant to whatever protocol it is using.

When I wondered whether "someone out there [could] fork Crafty and produce a UCI version" I didn't mean a broken or eccentric UCI version. I obviously meant a useable UCI version.

You're (deliberately?) missing the point: the "problem" with Crafty is that it has some idiosyncrasies (always report score from white POV rather than engine POV, no or few configurable options), not that it doesn't support UCI.

You're (deliberately?) being contentious. An improved Crafty WB is very clearly not what I was wondering about. From my point of view, the fact that Crafty is WB is itself one of its major "idiosyncracies".

[Roger Brown]

IIRC this is also a Crafty-specific problem. When you run Crafty in WinBoard/XBoard, it also reports inverted scores, compared to other engines. Again, this is not something that would be solved by changing to another protocol, but by making the engine compliant to whatever protocol it is using.

When I wondered whether "someone out there [could] fork Crafty and produce a UCI version" I didn't mean a broken or eccentric UCI version. I obviously meant a useable UCI version.

You're (deliberately?) missing the point: the "problem" with Crafty is that it has some idiosyncrasies (always report score from white POV rather than engine POV, no or few configurable options), not that it doesn't support UCI.

You're (deliberately?) being contentious. An improved Crafty WB is very clearly not what I was wondering about. From my point of view, the fact that Crafty is WB is itself one of its major "idiosyncracies".

Wow.

I guess after that statement there is nothing to say.

And no, Evert is not being deliberately contentious. He, along with H.G., is very patiently trying to point out that Crafty has idiosyncrasies, including how it reports scores. Those idiosyncrasies have nothing to do with whether Crafty is UCI or WB.

Your statement about Crafty - indeed about an entire protocol - is far more contentious, but of course, is entirely your right to state.

The posters here, myself included, were trying to address what they thought were issues which could be addressed.

Your perspective on Crafty cannot be addressed at all.

Later.