Crafty UCI version

[bob]

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.

The intent was you can do anything you want if only you use it, with the exception of entering it in computer chess events. With permission (and several have done this) you can change and distribute so long as you distribute the source and keep the provenance clear...

The main intent is to prevent copies from being modified and then joining computer chess events. We already have enough SF/ippolit/ivanhoe clones/derivatives today. I tried to prevent my being a part of that back when it became apparent it would become a major problem (Le Petite, Voyager, Bionic, El Chinito, et. al.)

[hgm]

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.

Is there any reason why it cannot be used in normal XBoard analyze mode? It seems to me that if you have implemented it already in other modes, this should just be a matter of enabling it at the right time, (e,g, after receiving 'option MultiPV=N' with N != 1), which should be pretty trivial.

[Evert]

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.

Sure that's what he asked. What isn't clear is why he wants that, which is relevant: presumably he wants it to solve some particular problem that might be solvable in another way, but without knowing what that problem is it's impossible to say.

In the past I've seen people ask for UCI ports (port is a big word for this sort of thing, to be honest) of engines because they somehow assumed that this would make the program stronger. Other reasons might be that they can't figure out how to set options for CECP engines under their GUI (I understand some GUIs do this differently for UCI and CECP, but I have no personal experience with this). There can be many reasons for such a question, and it's not obvious a-priory that the best solution to any of them is to make a UCI version.

Hence the question: why?

If I asked if someone could make a CECP version of Stockfish, the responses I expect are:
1. Why?
2. Do it yourself.

These would probably come in the reverse order, which I personally find rude, but there you go. Either way, "why?" is not an unreasonable question: Stockfish is perfectly functional as-is. What added benefit is there to making a CECP version of it? The second point is also not entirely unreasonable to ask of a programmer dealing with an open source project, but one can't just assume that the OP is a programmer (and as I said, I would find it rude to simply tell someone to go do it themselves).

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.

Not really.

If the reason for asking is that the user want to set certain options that are not currently settable through CECP because they are not exposed, then a) the problem simply is not that the program doesn't handle UCI, but rather that options are not exposed, and b) the problem will not magically go away if you do convert to UCI.

If I were to do a UCI conversion of a CECP engine, I would expose through UCI the options that are exposed through CECP, since I would look at the CECP implementation to figure out what options there are and how I'm supposed to code them up. No new options get added.
If I wanted to expose options to the GUI, I would add them to the existing CECP code, not convert it to UCI first for the heck of it.

So UCI vs CECP is entirely orthogonal to the actual problem in that case.

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.

Largely irrelevant because CECP now does support options, but anyway: no, I don't think it's obvious that the request implies adding new options that don't exist yet - particularly if it's not clear how they would have to be implemented.

Changing a CECP program so it can communicate through UCI is relatively easy (although I've only ever done the reverse once, but one could of course always just build WB2UCI into the executable directly and call it a day). Adding new configuration options to an engine that isn't your own can be relatively hard.

[Evert]

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 suppose it depends on the engine.

Senpai was very easy to convert to CECP, but it may well be cleaner code than Bonanza (at least I when I look at the code I can understand what Senpai is doing, I can't say the same for what I've seen of Bonanza).

[Roger Brown]

If I asked if someone could make a CECP version of Stockfish, the responses I expect are:
1. Why?
2. Do it yourself.

You left out options #3 and 4.

3. What the deleted is CECP?

4. This is Stockfish. You cannot improve on its perfection...

These would probably come in the reverse order, which I personally find rude, but there you go. Either way, "why?" is not an unreasonable question: Stockfish is perfectly functional as-is. What added benefit is there to making a CECP version of it? The second point is also not entirely unreasonable to ask of a programmer dealing with an open source project, but one can't just assume that the OP is a programmer (and as I said, I would find it rude to simply tell someone to go do it themselves).

The poster has made it clear that he considers a major idiosyncrasy of Crafty is that it employs Winboard protocol. I think if an adapter is unsuitable that would mean that someone should go do it - purely to satisfy this one request. I think suggesting to the requesting someone that they should do it would not be a rude response...

Not really.

If the reason for asking is that the user want to set certain options that are not currently settable through CECP because they are not exposed, then a) the problem simply is not that the program doesn't handle UCI, but rather that options are not exposed, and b) the problem will not magically go away if you do convert to UCI.

If I were to do a UCI conversion of a CECP engine, I would expose through UCI the options that are exposed through CECP, since I would look at the CECP implementation to figure out what options there are and how I'm supposed to code them up. No new options get added.
If I wanted to expose options to the GUI, I would add them to the existing CECP code, not convert it to UCI first for the heck of it.

So UCI vs CECP is entirely orthogonal to the actual problem in that case.

Largely irrelevant because CECP now does support options, but anyway: no, I don't think it's obvious that the request implies adding new options that don't exist yet - particularly if it's not clear how they would have to be implemented.

Changing a CECP program so it can communicate through UCI is relatively easy (although I've only ever done the reverse once, but one could of course always just build WB2UCI into the executable directly and call it a day). Adding new configuration options to an engine that isn't your own can be relatively hard.

Well said.

Later.

[Ferdy]

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.

WB2UCI has this option already.

[OPTIONS]
Program=wcrafty-18.13.exe
InitString=resign 0
HashCommand=hash %iM
WhiteScore=true
OwnBook=true
;ShowThinkingMove=true
;Logfile=true
Visible=Ponder,Hash,OwnBook,Extras,Logfile,ShowThinkingMove,Computer

[hgm]

OK, so this problem:

Why doesn't it work under WB2UCI?

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

should just be considered 'user error'. I know nothing about WB2UCI, but it seems strange that such options have to be set through an obscure ini file, rather than through UCI options. Polyglot exposes all its relevant internal options to the GUI, so they can be set interactively (and then saved as well).

[syzygy]

The intent was you can do anything you want if only you use it, with the exception of entering it in computer chess events. With permission (and several have done this) you can change and distribute so long as you distribute the source and keep the provenance clear...

The main intent is to prevent copies from being modified and then joining computer chess events. We already have enough SF/ippolit/ivanhoe clones/derivatives today. I tried to prevent my being a part of that back when it became apparent it would become a major problem (Le Petite, Voyager, Bionic, El Chinito, et. al.)

Thanks for the clarification.

That means that someone could create an UCI port of Crafty and distribute it (with source). Maybe one day you would even integrate it into the official Crafty

[syzygy]

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.

Sure that's what he asked. What isn't clear is why he wants that, which is relevant:

His question is pretty clear. I don't see why he needs to justify it. He simply does not like the hassle of having to configure adapters.

presumably he wants it to solve some particular problem that might be solvable in another way, but without knowing what that problem is it's impossible to say.

He told you the solution (UCI port of Crafty), so no need to wonder what the problem might be.

Of course asking a question does not hurt, but insisting on "what's the point" is not really useful imho.

[hgm]

His question is pretty clear. I don't see why he needs to justify it. He simply does not like the hassle of having to configure adapters.

When people make seemingly pointless requests, it is always a good idea to let them justify those. Because very often they are after a result that is that might be achieved in a much better way, or which won't be reached by what they propose at all.

He told you the solution (UCI port of Crafty), so no need to wonder what the problem might be.

But we know that porting Crafty to UCI doesn't really change a thing for him, compared to, say, bundling Crafty with a pre-configured WB-to-UCI adapter. So it seems he is misguided. It is in general unwise to embark on a difficult and elaborate task when there is doubt whether this is really what the person requesting it wants.

This might all sound a bit patronizing towards the OP. But the problem is that if the OP had the knowledge to make an accurate judgement about this, he would not be posting this request. He would have done the job himself, and be announcing the port here...