Crafty UCI version

[syzygy]

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.

He's not misguided. He only was confronted with people preferring to show off their "intelligence" rather than trying to be helpful.

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.

A reasonable reader would have understood that from the opening post.

He happened not to formulate his question in a way that fit your narrow view of things. That does not make him misguided.

[hgm]

He's not misguided. He only was confronted with people preferring to show off their "intelligence" rather than trying to be helpful.

If that is your opinion, then you are apparently misguided too...

But you are free to be 'helpful', of course, and do what he asks!

[Evert]

His question is pretty clear.

It's not really a question though: "can someone make a UCI port of Crafty?"- Answer: yes, someone can do it. It's actually a request: I'd like one, would someone be able/willing to make one?

And then, it's useful to know more about what someone is asking, and why.

I don't see why he needs to justify it.

Of course he doesn't, and if you think I ever said anything to the contrary you need to read more carefully. I asked for clarification.

He simply does not like the hassle of having to configure adapters.

That is not something you can infer from the original post, which is what prompted me to ask why he wanted it.

Now, he could have just said something like, "the GUI I use/like works better with UCI than CECP engines" and that's all fair and good. Instead there are some vague statements about "setting options of UCI engines in a typical GUI is easier", which makes no real sense to me (it could well be that most UCI engines expose more options than CECP engines, I don't know, but that says more about those engines than about UCI vs CECP), and I don't know what a "typical GUI" is supposed to be. However, trying to clarify that gets followed up by some annoyed and passive-agressive sniping.

So really, from my perspective, I ask a few simple questions and get a load of unneeded hostility in return.

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.

Come on, you're smarter than that.

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

I don't, but none of the first-page posts made it particularly clear.

"UCI works better" is not an answer to the question, because it's not factually true. It may be subjectively true (or false!) but then it is useful to know why that is the case. Note that this isn't about anyone being "right" or "wrong", just about understanding a point of view.

[Evert]

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.

A reasonable reader would have understood that from the opening post.

"useable" is not a precise term and can mean something very different for you, me or the OP.

Being clear is the foundation of all effective communication. A first step to being clear is to make sure that the other side knows what you mean.

[Roger Brown]

He's not misguided. He only was confronted with people preferring to show off their "intelligence" rather than trying to be helpful.

Count me out on two counts. I am not sufficiently knowledgeable in this arena to show off anything and I did offer a suggestion. Marek could at least have pointed out why that suggestion would not do.

As I indicated, if nothing else will do...

Before, UCI engines would be outside of my consideration in Winboard. Now I can enjoy UCI and Winboard engines in one place.

A reasonable reader would have understood that from the opening post.

Perhaps there is a deficit of reasonable persons because it is clear that there are a number of unclear areas from what was posted. I would even accept that I am unreasonable but not Evert or H.G.

As you implied below, the fact that persons have a different approach from yourself or understanding does not, in and of itself, make them unreasonable, unhelpful or braggarts.

He happened not to formulate his question in a way that fit your narrow view of things. That does not make him misguided.

Words to live by...

Later.

[Marek Soszynski]

It would be convenient for me if all my engines were of the same protocol. My engines tend to be drawn from the strongest engines. Nevertheless, I sometimes wish to experiment with other engines. All of the strongest engines are UCI, but a few of the weaker ones that I may try are not.

Although I can run non-UCI engines like Crafty on my GUIs (Aquarium, Scid...) they require "special measures" and don't quite run like the UCI ones, don't quite display like the UCI ones, and don't implement everything the UCI ones tend to do.

Now, if you read some of the posts here, that is the fault of the adaptor, the GUI, or even of me!

No. It's because they're a different protocol.

The heat and interest shown in this thread is because supporters of non-UCI protocols are anxious to defend their corner. They can do so without calling me misguided, thank you very much.

In my very opening post I gave the justification as to why Crafty isn't UCI. (I hope I was fair to its author.) As to why other engines aren't UCI is a matter for each of their individual authors. I never questioned the point of alternative protocols. Nevertheless, from my point of view and for my purposes, I wanted the GUI to have more control over the engine.

What I didn't expect was to be told, in effect, that it doesn't matter what protocol an engine is because users should attempt to engineer their own solutions anyway, which would at least deprive them of the time to ask pointless questions.

[hgm]

But you want to 'engineer your own solution'. Or rather, have someone do it for you: by porting engines you happen to take an interest in to another protocol. Which is by far the most cumbersome and inefficient way to do it.

If you want all your engines to be UCI, fine. Because a WB-to-UCI adapter is a UCI engine.

As you explain it, your only issue seems to be that the existing adapter is cumbersome to configure. And it would be far easier (and more generally useful) to fix that.

The argument that the problem should be solved in a difficult way, rather than an easy one, because it would provide you with an excuse to have someone else do it for you, is just not very convincing.

[Marek Soszynski]

As you explain it, your only issue seems to be that the existing adapter is cumbersome to configure. And it would be far easier (and more generally useful) to fix that.

The argument that the problem should be solved in a difficult way, rather than an easy one, because it would provide you with an excuse to have someone else do it for you, is just not very convincing.

That's having it both ways. There is a point to having different protocols. Vive la différence! Yet if a mere adapter resolves all translation issues, then that point is all but gone. Not that we have an adequate adapter, which belies the idea that it is trivial let alone doable for every possible engine.

I never thought that anyone would do my bidding; I was being wistful.

[Evert]

It would be convenient for me if all my engines were of the same protocol. My engines tend to be drawn from the strongest engines. Nevertheless, I sometimes wish to experiment with other engines. All of the strongest engines are UCI, but a few of the weaker ones that I may try are not.

I don't think anyone would argue that it wouldn't be easier if there was just the single protocol, but that's not the world we live in.

Although I can run non-UCI engines like Crafty on my GUIs (Aquarium, Scid...) they require "special measures" and don't quite run like the UCI ones, don't quite display like the UCI ones, and don't implement everything the UCI ones tend to do.

Now, if you read some of the posts here, that is the fault of the adaptor, the GUI, or even of me!

No. It's because they're a different protocol.

It really isn't.
There is no reason a GUI could not present a UCI and a CECP engine to the user in the same way. Both protocols are equally functional and offer a similar range of features (CECP has facilities for chess variants, sends more "meta-data" to the engine and allows engines to resign or offer draw, but I think that's the extend of the difference).
Really, all the difference it should make is whether you tick a box that says "UCI" or "CECP" - assuming that the GUI is unable to do some sort of auto-detection, which would make even that unneeded (but still desirable because the user should be able to override it if the GUI gets it wrong somehow, or one mode or the other works better).

If it's less transparent than that, then yes, that is the fault of the GUI - which is not necessarily something that is easy to fix.

The heat and interest shown in this thread is because supporters of non-UCI protocols are anxious to defend their corner. They can do so without calling me misguided, thank you very much.

Funny. The only protocol-bashing I see here is of CECP, and it's entirely gratuitous.

In my very opening post I gave the justification as to why Crafty isn't UCI. (I hope I was fair to its author.)

I don't know that I'd say it was the reason, I'll leave that for Bob to comment on if he wants, but I would think a more obvious reason is that Crafty pre-dates UCI.

Nevertheless, from my point of view and for my purposes, I wanted the GUI to have more control over the engine.

I still don't understand this point. You can treat a CECP engine exactly the same through the CECP protocol as you treat a UCI engine: it has exactly the same control. You can give the engine more control if you like (resign, draw offer, don't assume it doesn't have an own book) but you don't have to.

What I didn't expect was to be told, in effect, that it doesn't matter what protocol an engine is because users should attempt to engineer their own solutions anyway,

No one told you that. What you were told is that the perceived difference you claim (control) has nothing or very little to do with the protocols - the protocol shouldn't matter.
Now, you have an issue with the way your GUI of choice (which one, by the way?) works with CECP engines. That's unfortunate, but perhaps it's something that can be solved reasonably well with some effort. Changing Crafty to UCI is a lot of effort, and is not guaranteed to solve the problem you have (which is still no more concrete to me than "it's not UCI").

So if you want to be constructive about it, perhaps you could mention the GUI you're using and what it is exactly that is not working in the way you think it should. It's impossible to improve software without that kind of detailed feedback.

[chessico]

So if you want to be constructive about it, perhaps you could mention the GUI you're using and what it is exactly that is not working in the way you think it should.

Well, I use software from chessbase. From what I have heard many people do. It supports uci and is, dare I say it, a kind of standard, isn't it? I mean, in the real world, where there are chessplayers, not programmers, geeks, or other intelligent people. In these days, after my geeky days are over, I certainly won't use an adapter, however well written it may be, in order to use an engine. Most chessplayers I know would not do such a thing.
I think things are quite easy: If you don't support uci natively you will exclude your engine from being widely used. It's as simple as that. It's a shame, I would certainly like to have a crafty I can use in Fritz, CB, I am sure some real world people, apart from the geeks, remember the name from the past and would also like to use it, for a change from their preferred SF, Komodo or Houdini, but they won't get it. Sad, but it seems there is nothing one can do about it.