Crafty UCI version

[syzygy]

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!

The problem is that it is not legal, unless Bob gives permission. So this discussion can be kept very short.

[Roger Brown]

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.

Hello Carl,

I am unable to assess the greatness of the idea, but at least one suggestion was offered which would transparently offer the poster what he wanted.

He has not commented on it and interestingly, the investment of his time would be far less than on someone else's to re-fit Crafty.

Incidentally, when you mention "huge GUI advantages" you might be surprised. With free guis like ChessGUI, Winboard and Arena, the advantages of one protocol over the other are unclear.

Later.

[Roger Brown]

* 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).

I will bite. When the bloat was contemplated, if streamlined code was important, why do it? Did it add Elo to Stockfish? Otherwise it seems strange that it was done...

[bob]

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.

It is pretty obvious YOU don't know much about computer chess. A program generally does NOT just read a file and make a move. There are LOTS of options. For example, when the book is built, what information is kept in the book from the original PGN input? Results? date? opponent ratings? How do you use those to help choose the move? What kinds of weights for each component? What about book learning? How do you do that?

The opening line selection software often plays the critical first 20 moves in a game. That has a MAJOR influence on the outcome. I've always said this is a part of the program..

Ditto for endgames. What do you do with endgame tables? Suppose the table says draw. Do you just play a random move? Do you try something like Crafty's "swindle mode"? Do you do something even better and try to play a drawing move that maximizes the chances or likelihood that the opponent will go wrong, assuming HE is not using the same endgame databases.

Look up the term GUI. Graphical User Interface. An interface does NOT actually do anything other than serve as a go-between for an application program and the user. Nowhere else do you see a GUI that actually does anything other than display the program's results in a user-friendly graphical way.

You should not lecture people on points you don't think about. Because you are dead wrong.

[bob]

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.

Can you specify these "huge GUI advantages"?

For example, what does UCI allow that xboard can't do? Other than handle the opening book and endgame tables which a GUI has no business doing in the first place. Do you think FIDE/USCF would allow a blind player to enter a tournament, where they have to have a helper to make the moves and tell them what the opponent played, and then allow that helper to play the opening moves himself since openings are just variations written in a book?

[kranium]

* 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).

I will bite. When the bloat was contemplated, if streamlined code was important, why do it? Did it add Elo to Stockfish? Otherwise it seems strange that it was done...

Hi Roger-
The ability to see endgame win/draw/loss info from middlegame (or even earlier), seems to significantly help. The engine can make smart decisions concerning simplification, direction, etc.

In general there's a modest ELO improvement, but I don't have any info for SF (or Komodo).

Robert Houdart posted this:

With the 6-men on a normal hard disk I find the strength improvement of 5 to 10 Elo I reported above for 60"+1" games, played between Houdini 4 with and without table bases.
Cheers,
Robert

I experienced something similar when testing my implementation in Fire 4 last summer.
Norm

[Roger Brown]

Can you specify these "huge GUI advantages"?

For example, what does UCI allow that xboard can't do?

[SNIP]

Hello Dr. Hyatt,

Even more to the point, there are free guis which allow the user to set options globally for book handling, egtb's path etc. for engines employing both protocols.

Winboard does that now and it is free. There are other guis, such as ChessGUI that do the same thing.

Sometimes it seems as if the critics never actually try to use the thing (protocol, gui etc.) they criticise before criticising it...

Sigh.

Later.

[syzygy]

* 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).

I will bite. When the bloat was contemplated, if streamlined code was important, why do it? Did it add Elo to Stockfish? Otherwise it seems strange that it was done...

It's just more of the usual. This is what code bloat means:

Code bloat is the production of code that is perceived as unnecessarily long, slow, or otherwise wasteful of resources. Code bloat can be caused by inadequacies in the language in which the code is written, inadequacies in the compiler used to compile the code, or by a programmer. (...)

Often, bloated code can result from a programmer who simply uses more lines of code than the optimal solution to a problem.

[syzygy]

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.

Can you specify these "huge GUI advantages"?

I'll try to help the TS.

There are two points.

The first point is that if Crafty supported UCI, that would make it slightly easier to use Crafty with GUIs that only support UCI. There are always other ways to make it work, but they are slightly more cumbersome.

The second point is that if Crafty supported UCI options (or xboard/winboard options, for that matter), that would also make it easier for many people to configure Crafty. (Apparently Crafty relies on configuration files whereas more recent versions of the xboard/winboard protocol offer a "standard" way of configuration through the GUI.)

These points are really two separate points, even if they might be one and the same point in the view of the TS. But they are not unreasonable points and they do not mean that either protocol is superior to the other or anything like that.

[bob]

Can you specify these "huge GUI advantages"?

For example, what does UCI allow that xboard can't do?

[SNIP]

Hello Dr. Hyatt,

Even more to the point, there are free guis which allow the user to set options globally for book handling, egtb's path etc. for engines employing both protocols.

Winboard does that now and it is free. There are other guis, such as ChessGUI that do the same thing.

Sometimes it seems as if the critics never actually try to use the thing (protocol, gui etc.) they criticise before criticising it...

Sigh.

Later.

BTW, "Dr. Hyatt?" We have known each other how long? Moderation, etc? Bob works better for me.

Bob