Crafty UCI version

[hgm]

Well, I think that is clear now that a good WB-to-UCI adapter would for once and for all do away with these requests for engaging in counter-productive protocol changes, so there really isn't much left to say on this topic.

[Marek Soszynski]

Well, I think that is clear now that a good WB-to-UCI adapter would for once and for all do away with these requests for engaging in counter-productive protocol changes, so there really isn't much left to say on this topic.

Not at all. Posters other than myself have questioned Crafty's WB implementation (not fixed by the adapter) and mentioned GUIs' generally favouring UCI over WB, to say nothing of what this particular user favours.

Nevertheless, you may be right about "isn't much left to say".

[hgm]

Not at all. Posters other than myself have questioned Crafty's WB implementation (not fixed by the adapter) and mentioned GUIs' generally favouring UCI over WB, to say nothing of what this particular user favours.

Nevertheless, you may be right about "isn't much left to say".

Well, as to Crafty you have been making the wrong request: what you really want is it to support new features, and be cured of its non-compliancies. While you originally asked for conversion to UCI, which would do nothing of that. As I explained, the adapter could take care of many non-compliancies as well. New features of course might need extensive work to the core of the engine.

A WB-to-UCI adapter is a UCI engine, so it would solve any GUI's 'favoring of UCI engines'. It would give you exactly what you asked, but without sending people on a wild goose chase that even if it were succesful would only benefit users of a single engine, rather than the problem in general.

[Werewolf]

To me it seems clear what the original poster wants: a Crafty which has the odd behaviour addressed and supports UCI.

That is a reasonable request.

[bob]

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.

Crafty simply uses "white point of view" and has for 20 years now. I think it is much easier to understand when you see - is good for black, + is good for white. The "self point of view" makes you have to determine which side the program is playing to determine which color is better. A personal preference of course. I might add a POV option to disable this since quite a few get confused.

However, when doing things like annotating a game, white POV is much clearer to me since normal annotate symbols are white point of view (+/- is good for white, for example)

[bob]

Well, I think that is clear now that a good WB-to-UCI adapter would for once and for all do away with these requests for engaging in counter-productive protocol changes, so there really isn't much left to say on this topic.

Not at all. Posters other than myself have questioned Crafty's WB implementation (not fixed by the adapter) and mentioned GUIs' generally favouring UCI over WB, to say nothing of what this particular user favours.

Nevertheless, you may be right about "isn't much left to say".

Not sure what you mean by "questioned Crafty's inboard implementation." 90% of xboard protocol came DIRECTLY from Crafty. I used to send code/ideas to Tim Mann all the time (i.e. get rid of edit to resume adjourned games and send the move list instead so that repetitions would not be overlooked, things like player names, player ratings, whether the opponent is a computer or not, the list goes on and on. The only thing I have not yet done in normal mode is a multiPV option. Crafty certainly has this in the annotate command for going over games, just not in game play. It is such an ugly efficiency issue...

[bob]

Not at all. Posters other than myself have questioned Crafty's WB implementation (not fixed by the adapter) and mentioned GUIs' generally favouring UCI over WB, to say nothing of what this particular user favours.

Nevertheless, you may be right about "isn't much left to say".

Well, as to Crafty you have been making the wrong request: what you really want is it to support new features, and be cured of its non-compliancies. While you originally asked for conversion to UCI, which would do nothing of that. As I explained, the adapter could take care of many non-compliancies as well. New features of course might need extensive work to the core of the engine.

A WB-to-UCI adapter is a UCI engine, so it would solve any GUI's 'favoring of UCI engines'. It would give you exactly what you asked, but without sending people on a wild goose chase that even if it were succesful would only benefit users of a single engine, rather than the problem in general.

Have I missed some "non-compliance" somewhere along the way? The only thing I know I don't do is multi-PV. And I never noticed that being a xboard protocol requirement.

[bob]

To me it seems clear what the original poster wants: a Crafty which has the odd behaviour addressed and supports UCI.

That is a reasonable request.

What is "odd behavior"???

[hgm]

Have I missed some "non-compliance" somewhere along the way? The only thing I know I don't do is multi-PV. And I never noticed that being a xboard protocol requirement.

Strictly speaking you are right that there is none, because the specs do not address it. But the OVERWHELMING majority of all WB engines report scores from side-to-move POV during analysis, so that is the de-facto standard. Crafty is one of the very few engines that uses white POV.

The problem is that the protocol specs were drawn up at the time where XBoard did not do anything with scores (or PVs, for that matter), so that engines could do pretty much as they wanted, without any real consequences. But nowadays GUIs are expected to adjudicate games based on those scores, make graphs of them comparing the score of both engines, detect blunders from score drops, etc. All this becomes basically broken is an engine reports in the opposite way as the GUI expects.

XBoard has an option -first/secondScoreIsAbs that can be used flip black-to-move scores and restore the functionality of these features for Crafty. But apparently WB2UCI does not have such a 'work-around' option, and is hard-wired for the most-common case. This leads to complaints about Crafty like people are now voicing here.

Not sure how it is with Crafty and multi-PV. Does it really not implement that, as people were claiming here, or is it just that WB2UCI doesn't support it?

[hgm]

To me it seems clear what the original poster wants: a Crafty which has the odd behaviour addressed and supports UCI.

That is a reasonable request.

No, it seems an unreasonable request. Because the UCI driver code that would have to be added to Crafty, can be put much easier in a seperate (adapter) program, with exactly the same effect. (Namely that Crafty would behave as a UCI engine.) And then it would not only work for Crafty, but for some 500 other WB engines as well.

So basically the OP asks someone to do much more work than needed for something 500 time less useful than it could be. That does not really seem reasonable at all.