Crafty For iPod

[michiguel]

But Crafty uses Xboard, not UCI. Maybe it's time for a UCI Crafty.

There will probably never be such a time.

Why not? Although UCI has some problems, it's cleaner and less demanding overall than the xboard protocol.

Cleaner? what's clean about sending all the moves since the beginning of the game?

Miguel

Symbolic has different command processors for UCI, xboard, and console (interactive). The default is "console", but this can be overridden by a command line option. The three command namespaces are entirely separate.

Each command processor is implemented as a class, and the three command processor classes share the same base classes so there's a minimum of duplicated code. Each is also implemented as a thread that's driven by an event munching run loop. A separate thread object of the WatchTask class handles input polling, input text processing, and signals by sending the appropriate events to the command processor thread. (The WatchTask thread also handles nested command file input and all text output.)

At start-up time, the selected command processor instantiates an object of the MetaSearch class. This object is the interface to the search and takes care of all move selection work thus keeping a lot of code out of the command processors.

It would be relatively easy to add a new command processor class should a new protocol be developed and deployed.

[bob]

Bob,

With respect, I think Steven is pointing out that most of your objections are not real objections and can be overcome if you had the inclination. Come on - let's face it UCI is *THE* chess computer protocol - Winboard is dead. *ALL* of the top engines support UCI. I don't think anyone accepts the claim that UCI reduces Crafty's playing strength as a reason not to implement it.

Anyway I really hope you implement UCI for Crafty - if only for the users .

Best regards,

Steve

1. I don't believe "winboard is dead." Evidence is a ton of programs that still use winboard.

2. I never said "UCI weakens Crafty." That would be impossible to say since crafty doesn't do UCI. The issue with UCI is that it is a different way of operating for the engine. Crafty decides what to ponder, when to ponder, how long to ponder, ie it makes _all_ decisions related to playing chess, and expects the GUI to simply relay moves back and forth and display the board, nothing more, nothing less.

The issue is it would pose some serious rewriting in Crafty. My only goal has been to write a computer chess program that can play chess with someone. I'm not hung up on the GUI. But I am hung up on the GUI staying _out_ of the chess-playing business. If the root position is a EGTB position, I do _not_ want the GUI to make a move. If the root position is a book position, I do _not_ want the GUI to make that move either. That responsibility belongs to the chess engine.

If someone wants to write a GUI that usurps much of the chess engine responsibility, that's fine. But I am not interested in using it and modifying my code to comply with whatever communication protocol it chooses to implement.

And to say "there is a protocol but you don't have to follow it" is about as ridiculous a concept as I have ever heard. One that doesn't interest me in the least...

Anyone that wants to is free to make such changes to Crafty. I'd rather modify the GUI and remove the excessive intrusion myself.

[bob]

I think the idea is that some think it is reasonable to remove what we would call the "bare search" from a normal engine, and make _that_ the engine. No command-line interface at all, no game state, no opening book, no timing decisions, etc. Which is OK. But it is not the way I designed my code, and I am not interested in a major rewrite to make it fit into this broken (IMHO) way of designing a general-purpose interface.

Xboard / winboard is easy to use. It does not intrude into the game whatsoever, it is a purely passive interface that sits between the end user (whether this is a human, another computer, or even a chess server is irrelevant) and the chess engine.

The xboard protocol won't be dead until at least the point where I am dead, because this is how I intend to interface my program to the end user unless some _better_ protocol/approach comes along. I would like to see a UCI-like option mechanism so that engine tuning parameters can be exposed to users in a easy-to-adjust way. But that is the only thing I like about UCI and that could be done just as easily in xboard.

[michiguel]

I think the idea is that some think it is reasonable to remove what we would call the "bare search" from a normal engine, and make _that_ the engine. No command-line interface at all, no game state, no opening book, no timing decisions, etc. Which is OK. But it is not the way I designed my code, and I am not interested in a major rewrite to make it fit into this broken (IMHO) way of designing a general-purpose interface.

Xboard / winboard is easy to use. It does not intrude into the game whatsoever, it is a purely passive interface that sits between the end user (whether this is a human, another computer, or even a chess server is irrelevant) and the chess engine.

The xboard protocol won't be dead until at least the point where I am dead, because this is how I intend to interface my program to the end user unless some _better_ protocol/approach comes along. I would like to see a UCI-like option mechanism so that engine tuning parameters can be exposed to users in a easy-to-adjust way. But that is the only thing I like about UCI and that could be done just as easily in xboard.

This has been discussed quite a bit in the winboard forum. In fact, HG Muller implemented an experimental version (I still have to try it, when I am done with few things in my to-do list). It is not conceptually difficult and uses the "feature" command. I believe sooner or later we will have this.

BTW, the grammar that UCI uses to implement this is suboptimal to say the least.

Miguel

[sje]

For the record, let me state that I am in general agreement with Bob in that I too do not believe that a GUI should absolve a putative chess program author from actually writing a real chess program and not just an engine. Move generation, search, and evaluation are important parts of any chess playing program, but they are not the only parts.

The tradition for years has been that a chess program included as work done by the author: the opening book (creation and access), a text interface, a chess notation coder/decoder, a command set to allow experimentation with parameters, a chess clock emulation along with time management, and the abilities to intelligently resign or make/accept draw offers. When all or most of the above are handled by the GUI, there are two big concerns:

1) Has control been unfairly taken away from the engine author?

2) Is the engine author really a chess programmer, or is he a lazy hacker who has cobbled together an engine mostly from public sources?

----

Now some have misinterpreted my earlier comments. Let me repeat:

"While A GUI may handle extra (and unwarranted) tasks, it is still possible to deploy the GUI so it does only plain graphical display and interactive mouse input."

And

"Just because some may overextend the domain of a GUI doesn't mean that I am participating in that overextension by my using the GUI only for move I/O."

[Steve Maughan]

.... Crafty decides what to ponder, when to ponder, how long to ponder, ie it makes _all_ decisions related to playing chess, and expects the GUI to simply relay moves back and forth and display the board, nothing more, nothing less.

I think philosophically you have anthropomorphized Crafty too much . Using your logic it would be acceptable for Crafty to decide to not play chess at all on some days! IMHO it is the *user* who should be able to decide how and when Crafty plays chess. The *user* should be in control. And this should be done using a (G)graphical (U)ser (I)nterface i.e. the GUI.

Best regards,

Steve

[mhull]

.... Crafty decides what to ponder, when to ponder, how long to ponder, ie it makes _all_ decisions related to playing chess, and expects the GUI to simply relay moves back and forth and display the board, nothing more, nothing less.

I think philosophically you have anthropomorphized Crafty too much . Using your logic it would be acceptable for Crafty to decide to not play chess at all on some days! IMHO it is the *user* who should be able to decide how and when Crafty plays chess. The *user* should be in control. And this should be done using a (G)graphical (U)ser (I)nterface i.e. the GUI.

Best regards,

Steve

IMO, no. The designer of a computer chessplayer isn't obligated to allow the user to cannibalize the player, and mix-match it's parts with other chessplaying programs, such as a "GUI" that plays chess by selecting moves generated by multiple programs and books from multiple programmers. The designer is free to say, this is the player, like it or not. The interfaces will only interface. The interface isn't the player. Crafty is the player of all moves. Take it or leave it.

[bob]

.... Crafty decides what to ponder, when to ponder, how long to ponder, ie it makes _all_ decisions related to playing chess, and expects the GUI to simply relay moves back and forth and display the board, nothing more, nothing less.

I think philosophically you have anthropomorphized Crafty too much . Using your logic it would be acceptable for Crafty to decide to not play chess at all on some days! IMHO it is the *user* who should be able to decide how and when Crafty plays chess. The *user* should be in control. And this should be done using a (G)graphical (U)ser (I)nterface i.e. the GUI.

Best regards,

Steve

I agree, and this is _exactly_ how winboard/xboard works. You can tell crafty to ponder or not ponder, but not what to ponder, when to ponder, etc. You can tell crafty what type of time control you want to use. You can't tell it how to allocate that time any more than you can tell your human opponent how to use his clock time. I don't see this as an issue at all. I've just invested way too much time in crafty's pondering code, swindle mode code, time allocation code, time usage code, book learning code, egtb usage code, etc, to have the GUI usurp part or all of that...

[bob]

For the record, let me state that I am in general agreement with Bob in that I too do not believe that a GUI should absolve a putative chess program author from actually writing a real chess program and not just an engine. Move generation, search, and evaluation are important parts of any chess playing program, but they are not the only parts.

The tradition for years has been that a chess program included as work done by the author: the opening book (creation and access), a text interface, a chess notation coder/decoder, a command set to allow experimentation with parameters, a chess clock emulation along with time management, and the abilities to intelligently resign or make/accept draw offers. When all or most of the above are handled by the GUI, there are two big concerns:

1) Has control been unfairly taken away from the engine author?

2) Is the engine author really a chess programmer, or is he a lazy hacker who has cobbled together an engine mostly from public sources?

----

Now some have misinterpreted my earlier comments. Let me repeat:

"While A GUI may handle extra (and unwarranted) tasks, it is still possible to deploy the GUI so it does only plain graphical display and interactive mouse input."

And

"Just because some may overextend the domain of a GUI doesn't mean that I am participating in that overextension by my using the GUI only for move I/O."

There is another concern that is paramount to this discussion. A normal GUI, as in xboard/winboard, has _zero_ chess-playing ability, and I think it is perfectly legitimate for everyone to show up at an event and use xboard/winboard as an interface to play games in a tournament, whether it is an automated online event or a manually-operated event. But some GUIs go much further than that, playing opening moves, "learning" when a book move is bad and avoiding it in the future, "learning" when a book mvoe is good and preferring it in the future, managing the time usage, playing EGTB moves when the root position is 6 pieces or less, etc. That kind of GUI is perfectly acceptable, but it should only be used by _one_ program. And that is where things break down. One can use some of the available commercial GUIs and avoid having to write anything but the pure search code. I don't think those should be allowed to compete unless the GUI author is a part of the team that is entering a _single_ competitor...

[sje]

There is another concern that is paramount to this discussion. A normal GUI, as in xboard/winboard, has _zero_ chess-playing ability, and I think it is perfectly legitimate for everyone to show up at an event and use xboard/winboard as an interface to play games in a tournament, whether it is an automated online event or a manually-operated event. But some GUIs go much further than that, playing opening moves, "learning" when a book move is bad and avoiding it in the future, "learning" when a book mvoe is good and preferring it in the future, managing the time usage, playing EGTB moves when the root position is 6 pieces or less, etc. That kind of GUI is perfectly acceptable, but it should only be used by _one_ program. And that is where things break down. One can use some of the available commercial GUIs and avoid having to write anything but the pure search code. I don't think those should be allowed to compete unless the GUI author is a part of the team that is entering a _single_ competitor...

But how can cheating be determined? If I enter Symbolic in an event and use a UCI GUI, how do you know that I'm not using a book by somebody else, tablebases by somebody else, or learning by somebody else? Must I be restricted to the use of Xboard when there's a visually and logically better UCI GUI available?

I suppose I could spool Symbolic's log to a web site in real time so others may see exactly what's happening. But maybe not everyone is willing to do this. Some programs might not even create a log.