Crafty UCI version

[bob]

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?

it does not implement it in normal game play. The game annotation feature does this, but that is not the same code...

[syzygy]

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.

I won't try to guess who is deliberately misunderstanding who, but I would think that a reasonable reader of Marek's opening post, a reader willing to correct for any perceived misunderstanding on Marek's side, would have had no trouble understanding that what he is looking for is a fully functional UCI port of Crafty. A port that does not need an adapter and that exposes all its relevant options to a UCI GUI.

The argument that Crafty's problem is not that it does not support UCI but that it does not properly support winboard options is a bit disingenious. Suppose winboard did not support options, as was the case in the past, and then someone asks for a UCI port. Would anybody have misunderstood that request? I don't think so. UCI options are an integral part of UCI. So an UCI port implies UCI options. That Crafty does not fully support recent incarnations of the winboard protocol is pretty much irrelevant.

[hgm]

it does not implement it in normal game play. The game annotation feature does this, but that is not the same code...

I suppose that refers to the multi-PV. How about normal (XBoard) analyze mode? This is where people usually want it.

How can it be selected? The MultiPV option of UCI engines is translated by Polyglot to an XBoard engine-defined option:

feature option="MultiPV -spin 1 MAX 1"

This can be set interactively through the Engine Settings dialog, but the more recent XBoard's recognize the option (so that it has become a sort of protocol extension), and allow the user to interactively change its setting during analysis by right-clicking on the words 'less' or 'more' in the Engine Output window's header line. XBoard then sends a command

option MultiPV=N

to the engine.

Can this be used in Crafty?

[syzygy]

I'm wondering about Crafty's license:

Code: Select all

 *  All rights reserved.  No part of this program may be reproduced in any     *
 *  form or by any means, for other than your personal use, without the        *
 *  express written permission of the authors.

That seems to exclude the distribution of an UCI port of Crafty without the express written permission of Crafty's authors. Although "personal use" might cover distribution among a (very) restricted number of "friends".

However:

Code: Select all

 *  Copies of the source must contain the original copyright notice intact.    *

So it is legal to distribute the source? Or should this be read in the context of "personal use"?

Code: Select all

 *  Any changes made to this software must also be made public to comply with  *
 *  the original intent of this software distribution project.  These          *
 *  restrictions apply whether the distribution is being done for free or as   *
 *  part or all of a commercial product.  The authors retain sole ownership    *
 *  and copyright on this program except for 'personal use' explained below.   *

I suppose changes made "for personal use" need not be made public. So does the above passage mean that it is allowed to make changes to the software as long as they are made public?

What if someone makes a Crafty UCI port. Does the license permit distributing the result (including the modified source code and non-modified copyright notice and without changing its name)?

If this is not allowed, the best approach seems to be distributing a source code patch. But that requires users to compile their own version.

[hgm]

One supposes that most of the conditions are only relevant for those who can legally distribute the source, i.e. who have explicit written permission from Bob. For personal use you can always do anything, as no one would ever know...

The best approach is of course to write an adapter. Then you don't have to comply with any license agreement...

[syzygy]

One supposes that most of the conditions are only relevant for those who can legally distribute the source, i.e. who have explicit written permission from Bob.

You might be right, but the license isn't particularly clear on this point, in my view.

The full "no part may be reproduced" paragraph reads:

Code: Select all

 *  All rights reserved.  No part of this program may be reproduced in any     *
 *  form or by any means, for other than your personal use, without the        *
 *  express written permission of the authors.  This program may not be used   *
 *  in whole, nor in part, to enter any computer chess competition without     *
 *  written permission from the authors.  Such permission will include the     *
 *  requirement that the program be entered under the name "Crafty" so that    *
 *  the program's ancestry will be known.                                      *

That last sentence announces one condition that the express written permission will include. The license does not say, at least not in the same manner, that such permission will also include the requirements that "[c]opies of the source must contain the original copyright notice intact" and that changes be made public.

The best approach is of course to write an adapter. Then you don't have to comply with any license agreement...

An adapter is not going to turn a configuration file into UCI options. Well, one could write such an adapter, I guess. But it seems considerably easier to hack Crafty directly.

[syzygy]

According to Bob in this post:

People are free to fiddle around with all the changes they want to make to the Crafty source. But they can not (a) release the engine without releasing the source; (b) enter into any computer chess competition whatsoever.

But they can play and test all they want, and if they reach the point where all the code is original, they are free to do whatever they want...

So making a UCI port and distributing it, including the source, seems to be permitted (contrary to what I stated earlier in this thread).

It's not entirely clear though how to reconcile this with:

All rights reserved. No part of this program may be reproduced in any form or by any means, for other than your personal use, without the express written permission of the authors.

[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.

I won't try to guess who is deliberately misunderstanding who, but I would think that a reasonable reader of Marek's opening post, a reader willing to correct for any perceived misunderstanding on Marek's side, would have had no trouble understanding that what he is looking for is a fully functional UCI port of Crafty. A port that does not need an adapter and that exposes all its relevant options to a UCI GUI.

The argument that Crafty's problem is not that it does not support UCI but that it does not properly support winboard options is a bit disingenious. Suppose winboard did not support options, as was the case in the past, and then someone asks for a UCI port. Would anybody have misunderstood that request? I don't think so. UCI options are an integral part of UCI. So an UCI port implies UCI options. That Crafty does not fully support recent incarnations of the winboard protocol is pretty much irrelevant.

Hello Ronald,

I am not attempting to deliberately misunderstand anyone or to be disingenuous.

I suggested - and indeed H.G. has expounded on it - that an adapter would serve the stated purpose of the poster.

Indeed there was a point in time when Winboard did not support UCI engines at all. Then Polyglot was invented and that all changed.

There exists a current piece of software called wb2uci which enables Winboard engines to be used in a UCI only gui.

That solution - if improved - would serve not only for Crafty but for all WB protocol engines as well.

His comment about Crafty's protocol seems odd but he is entitled to it.

The suggestions that are being made were made to assist in accomplishing common tasks done with engines.

Of course he may want a UCI port/fork of Crafty and only that will do for his purposes.

The list of things I want is staggering.



Later.

[hgm]

An adapter is not going to turn a configuration file into UCI options. Well, one could write such an adapter, I guess. But it seems considerably easier to hack Crafty directly.

To 'hack Crafty directly' would require quite elaborate knowledge of its inner workings. This is far from trivial. I know, because I have hacked the Bonanza enginine, which was using its own, unique protocol to make it understand WB protocol. I can assure you that writing an adapter that edits a settings file and then restarts the engine would be far simpler. (At least, if the format and options of the settongs file are well documented in English.)

I guess one could even make a universal adapter that can be configured to handle a variety of settings files with different formats. E.g. where the configuration file of the adapter contains the line needed to set a certain option (like hash size) in the engine settings file, with the value in symbolic form, which then scans the settings file for a line that matches it, and replaces the value there by the requested one before starting the engine.

Of course if you want to set an option interactively, and the engine only reads its settings file at start-up, it presents a problem. Restarting the engine every time you change the multi-PV setting (and thus losing the hashed info from earlier searches) would be sort of a disaster.

But I guess it would be far easier to convince an engine author to do something about that than to completely change the protocol used in addition. If the complaint is that many of Crafty's options are not available in the Engine Settings dialog of XBoard (or other GUIs), then I would of course want to encourage Bob to do something about that, rather than encouraging someone else to fork Crafty.

[bob]

it does not implement it in normal game play. The game annotation feature does this, but that is not the same code...

I suppose that refers to the multi-PV. How about normal (XBoard) analyze mode? This is where people usually want it.

How can it be selected? The MultiPV option of UCI engines is translated by Polyglot to an XBoard engine-defined option:

feature option="MultiPV -spin 1 MAX 1"

This can be set interactively through the Engine Settings dialog, but the more recent XBoard's recognize the option (so that it has become a sort of protocol extension), and allow the user to interactively change its setting during analysis by right-clicking on the words 'less' or 'more' in the Engine Output window's header line. XBoard then sends a command

option MultiPV=N

to the engine.

Can this be used in Crafty?

Analyze mode in xboard came from crafty via Tim Mann. I added the feature to crafty then he added it to board. Works perfectly for me with xboard in that regard.

But as I mentioned, crafty only has multi-pv currently in the annotate command, which takes PGN as input, and makes comments/suggestions/finds blunders/etc depending on the annotate command given. This is not done through a GUI, it is a sort of off-line or background / batch thing.