Crafty UCI version

[Adam Hair]

Could someone out there fork Crafty and produce a UCI version?

Apologies accepted. Quite simply, it is easier to set up and change the parameters of a UCI engine within a typical GUI; moreover, the typical GUI will display all the main settable parameters.

Hello Marek,

Given your stated purpose, perhaps it might be easier to use wb2uci than to hack the engine?

Later.

Some winboard engines plus wb2uci have a tendency to crash under certain conditions.

Having said that, Crafty plus wb2uci has never given me any trouble.

[Modern Times]

UCI means that not-the-chess-engine can end-up playing part of the game (openings and endings). This is a wrong design

Not really. You can make the GUI do that, or you can tell the GUI not to. Your choice. I'd hardly call that wrong design.

[hgm]

A UCI version of Crafty would be convenient for me as all my other engines are UCI and all the strongest engines are. Got it? GUIs generally handle UCI engines more ably and easily than other engines from the perspective of this user. That's just how it is.

I don't think that is a protocol matter. WB engines can expose their options to the user just as easily as UCI engines. If an engine chooses not to expose its options, there is nothing for the GUI to handle even if the engine is UCI.

If your complaint is that Crafty relies on settings files for most of its options rather than allow the user to set them interactively through the protocol interface, then that is a valid complaint. But it would not be solved by converting the engine to UCI. You would still see an empty Engine Settings dialog in the GUI.

[mhull]

UCI means that not-the-chess-engine can end-up playing part of the game (openings and endings). This is a wrong design

Not really. You can make the GUI do that, or you can tell the GUI not to. Your choice. I'd hardly call that wrong design.

But logically, there is no reason to facilitate such options, since they serve only to disable an AI and create ethical conflicts in tournaments using the same chess-playing program, e.g. UCI chess player.

This is why it is a wrong design.

[lucasart]

UCI means that not-the-chess-engine can end-up playing part of the game (openings and endings). This is a wrong design

Not really. You can make the GUI do that, or you can tell the GUI not to. Your choice. I'd hardly call that wrong design.

But logically, there is no reason to facilitate such options, since they serve only to disable an AI and create ethical conflicts in tournaments using the same chess-playing program, e.g. UCI chess player.

This is why it is a wrong design.

I don't know who you are, but it's obvious that you don't know anywhere near enough about computer chess, to lecture a field of expert about what is "right" or "wrong" design.

Opening:
* playing opening moves is something completely trivial, with zero added value. you basically read a binary file (called an opening book), and you play the moves it tells you to play (slecting randomly as parametrized by the user).
* a GUI or an engine can do that equally well. It has nothing to do with the protocol CECP or UCI by the way. A CECP GUI could handle the book. Maybe Xboard can do it (if it can't then it definitely should).
* choosing the GUI instead of the Engine for that task is the correct design. There are a few GUIs, and hundreds of engines. That means only a few people have to write the same tedious book parsing code, instead of hundreds of engine developpers. It also means that enforcing book standards is possible (eg. PolyGlot). If every engine developper had his own book format, with the amount of engines around, it would be impossible to converge towards a standard. Fortunately, there are much fewer GUIs.

EGTB:
* They can be handled by the GUI (for adjudication), and/or by the engine.
* Here the problem is different. To get the best out of EGTB, you also need to handle EGTB in the engine, and it's not trivial (eg. syzygy has bloated SF by almost two thousand lines of code).
* Most engines do not have EGTB. So, if the GUI is able to do EGTB adjudication, it's a plus. For people running tournament, nothing is more time/electricity wasting than these idiotic 50 move shuffle, pawn push, 50 move circus start again etc.
* Again, this has absolutely nothing to do with UCI or CECP.

[Werewolf]

I was just wondering...

Could someone out there fork Crafty and produce a UCI version?

I realise Crafty's author, Bob Hyatt, doesn't like UCI as it cedes too much control to the GUI.

Very well then, let someone else do it while keeping to all the legal proprieties including publishing the changed code, etc.

I think this is a great idea and it's such a shame some people have landed on your thread just to bash your idea.
UCI has huge GUI advantages and to get Crafty into this format would be brilliant.

[Marek Soszynski]

I was just wondering...

Could someone out there fork Crafty and produce a UCI version?

I realise Crafty's author, Bob Hyatt, doesn't like UCI as it cedes too much control to the GUI.

Very well then, let someone else do it while keeping to all the legal proprieties including publishing the changed code, etc.

I think this is a great idea and it's such a shame some people have landed on your thread just to bash your idea.
UCI has huge GUI advantages and to get Crafty into this format would be brilliant.

Thanks Carl!

[Modern Times]

EGTB:
* They can be handled by the GUI (for adjudication), and/or by the engine.
* Here the problem is different. To get the best out of EGTB, you also need to handle EGTB in the engine, and it's not trivial (eg. syzygy has bloated SF by almost two thousand lines of code).
* Most engines do not have EGTB. So, if the GUI is able to do EGTB adjudication, it's a plus. For people running tournament, nothing is more time/electricity wasting than these idiotic 50 move shuffle, pawn push, 50 move circus start again etc.
* Again, this has absolutely nothing to do with UCI or CECP.

Agreed.

Many engines have EGTB code within them now, both UCI and winboard. Nothing to do with the protocol.

And almost every GUI will do EGTB adjudication, which is optional. If people don't like it, they don't select it.

Didn't earlier versions of the Fritz GUI actually play out the tablebase moves for the engines if you selected that option ? Maybe someone else can advise, I might be wrong about that. I guess that is adjudication taken a step further, but it was optional and I guess some people liked it. I don't and wouldn't select it. But I'd call that a GUI design choice, specifically a chessbase one....

[syzygy]

Bob can speak for, and defend, himself.

Yes, and if you ask a question on a general forum, anyone can answer. If you wanted an answer specifically from Bob Hyatt, you should have contacted him directly.

In this case you were sort of asking Marek why Bob is of the view that UCI takes too much control. It makes sense for Marek to leave that question to Bob instead of trying to answer it himself. (And I think Bob has answered it many times already on this forum.)

[syzygy]

UCI means that not-the-chess-engine can end-up playing part of the game (openings and endings). This is a wrong design

Not really. You can make the GUI do that, or you can tell the GUI not to. Your choice. I'd hardly call that wrong design.

But logically, there is no reason to facilitate such options, since they serve only to disable an AI and create ethical conflicts in tournaments using the same chess-playing program, e.g. UCI chess player.

This is why it is a wrong design.

I don't know who you are, but it's obvious that you don't know anywhere near enough about computer chess, to lecture a field of expert about what is "right" or "wrong" design.

Next time, read before you click "Submit" and simply delete such unhelpful comments. They don't bring the discussion forward one iota.

Opening:
* playing opening moves is something completely trivial, with zero added value.

The only reason that the engine cannot add value here is that the GUI does not let it.

The opening is often decisive for the outcome of the game. Leaving the opening to the GUI makes the GUI a part of the engine. I find that very strange. Do GUIs have Elo ratings? They play the most important part of the game, so they should have!

Lots of value can be added to the process of choosing book moves. Book moves may have statistics and evaluations stored with them. The engine might perform searches of its own for verification, maybe dependent on the time control. The book might be learning from previous games. The engine might choose its opening dependent on who is its opponent (unfortunately UCI will not inform it of the name or rating of its opponent).

Lots and lots of value can be added to playing from book. UCI has essentially killed off all of that. (It is not UCI that is to blame here, but its success...)

It is true that UCI does not forbid engines to play from book, but it is definitely part of UCI's philosophy and the protocol actually explicitly foresees it.

you basically read a binary file (called an opening book), and you play the moves it tells you to play (slecting randomly as parametrized by the user).

By the user? Why not let the user play the middle game as well?

Your point of view might be two engines playing 40,000 STC games via cutechess for testing purposes. I completely agree that under those conditions there is little value in letting the engines choose opening moves. There may also be tournaments where you simply don't want the opening book to make a difference, so again you should let the GUI pick the starting position. But these are special circumstances. In general, playing the opening is an integral part of game playing and should therefore not be isolated from the engine.

* a GUI or an engine can do that equally well. It has nothing to do with the protocol CECP or UCI by the way. A CECP GUI could handle the book. Maybe Xboard can do it (if it can't then it definitely should).

It does have something to do with UCI (see below). And it seems to be a fact that most UCI engines don't know how to handle a book.

It also means that enforcing book standards is possible (eg. PolyGlot). If every engine developper had his own book format, with the amount of engines around, it would be impossible to converge towards a standard.

I agree a common book format is convenient, but it is also very limiting.

Anyway, UCI does allow engines to use their own book. But at the same time it obliges GUIs to have book code:

* by default all the opening book handling is done by the GUI, but there is an option for the engine to use its own book ("OwnBook" option, see below)

* <id> = OwnBook, type check
this means that the engine has its own book which is accessed by the engine itself. if this is set, the engine takes care of the opening book and the GUI will never execute a move out of its book for the engine. If this is set to false by the GUI, the engine should not access its own book.

EGTB:
* They can be handled by the GUI (for adjudication), and/or by the engine.

GUI adjudication is useful when playing 40,000 test games or whenever it is not very important whether adjudication may change the outcome of the game (because it does, now and then).

There are many uses of chess engines where GUI adjudication is not an option at all. I cannot imagine that a human playing against an engine would accept that his game is adjudicated by the GUI.

But you know what some GUIs do? They do not adjudicate the game when a TB position is reached, but they take over playing the game! And this accounts for the vast majority of bug reports that I have received.

For people running tournament, nothing is more time/electricity wasting than these idiotic 50 move shuffle, pawn push, 50 move circus start again etc.

Is running tournaments not all about wasting time and electricity?