UCCI2WB

[PK]

Is there any advantage in keeping track of the side played by the engine?

Asymmetric eval.

[syzygy]

The only difference is that in CECP the side played by the engine is persistent

Is there any advantage in keeping track of the side played by the engine?

Well, yes.

I don't know about you, but I don't want to make a move and then have to tell my opponent that it's their turn.

For me it is exactly the opposite. When I use my engine from the command line, I am only testing it and this is much easier if I get to control when the engine starts calculating.

Of course engine programmers should feel free to implement a full-fleged command-line playing mode. But there is no reason that it has to be the same mode that supports the GUI (and in fact even gnuchess and crafty distinguish between cli mode and xboard mode).

The GUI knows when the engine is supposed to start calculating. Having the engine decide this as well can only be a source of bugs.

But the GUI does know when the engine is supposed to start calculating: if it's on move and not in force mode.

As I said, this is a source of bugs and it wins exactly nothing. Almost all programmers can get UCI right, many programmers can't get the xboard protocol right. Of course one can argue that if a programmer can't get the xboard protocol right he has no business interfacing his engine to xboard/winboard, but that's why UCI has so clearly won.

Note that in CECP the GUI can always switch the engine back into force-mode after it's played a move. That makes it behave as you suggested.

Then you change the protocol.

[Evert]

For me it is exactly the opposite. When I use my engine from the command line, I am only testing it and this is much easier if I get to control when the engine starts calculating.

Of course engine programmers should feel free to implement a full-fleged command-line playing mode. But there is no reason that it has to be the same mode that supports the GUI (and in fact even gnuchess and crafty distinguish between cli mode and xboard mode).

Never said it has to be. Just wanted to point out that there are reasons for wanting to know what side you're playing.

As I said, this is a source of bugs and it wins exactly nothing. Almost all programmers can get UCI right, many programmers can't get the xboard protocol right.

That's news to me, and I find it surprising. Getting the communication protocol right is not the hard part of writing a chess program.

Of course one can argue that if a programmer can't get the xboard protocol right he has no business interfacing his engine to xboard/winboard, but that's why UCI has so clearly won.

I didn't realise there was a competition...
But I'll go one further: I would argue that if you can't get CECP right you probably have no business trying to write a chess program in the first place. As I said, it's not the hard part of the problem. For the record: despite it being a poor fit to the internal workings, Jazz understood UCI before it understood CECP.

Note that in CECP the GUI can always switch the engine back into force-mode after it's played a move. That makes it behave as you suggested.

Then you change the protocol.

In what sense? Force-mode is part of the protocol, and the GUI is free to switch the engine to force mode if it wants to. I would say that the protocol gives you the freedom to do that, if you want.
I do suppose pondering is out though...

[hgm]

I think it would just change the way you use the protocol. Sending 'force' just before every command, except for 'usermoves' that are ponder hits, to make sure the engine would never remember what side it must play for more than one command should work fine on existing engines, and I don't really see a downside to it. (It could be argued it is more robust, and would tolerate engine non-compliancies that otherwise would be fatal. Of course in practice that would be a disadvantage, as it would encourage development of non-compliant engines.)

That some engines have difficulty getting WB protocol working is usually not the GUIs fault, so it cannot be blamed on that it is difficult for the GUI to know when the engine will start thinking. I don't have any statistics on whether UCI or WB engines have more trouble to get them running. Impllementing a WB engine has always seemed pretty trivial and intuitive to me:
- When you receive a move, start thinking, unless you are in force mode
- When you receive 'go', start thinking even when in force mode (and leave force mode)
- When you receive 'force', go to force mode.
The problems starting engine developers have are due to not flushing the output, not reliably detecting input during ponder search, and stuff like that. Which would break UCI implementations in exactly the same way as WB implementations. Oops, my 'bestmove' stays buffered, and now my engine hangs...

[syzygy]

That's news to me, and I find it surprising. Getting the communication protocol right is not the hard part of writing a chess program.

Once you understand recursion there is nothing difficult about a chess engine.

Of course one can argue that if a programmer can't get the xboard protocol right he has no business interfacing his engine to xboard/winboard, but that's why UCI has so clearly won.

I didn't realise there was a competition...

UCI has no serious competition, in fact.

But I'll go one further: I would argue that if you can't get CECP right you probably have no business trying to write a chess program in the first place.

That's what I mean. I'll just say Stefan Meyer-Kahlen had a different attitude when he designed the UCI protocol.

Note that in CECP the GUI can always switch the engine back into force-mode after it's played a move. That makes it behave as you suggested.

Then you change the protocol.

In what sense? Force-mode is part of the protocol, and the GUI is free to switch the engine to force mode if it wants to. I would say that the protocol gives you the freedom to do that, if you want.
I do suppose pondering is out though...

If you expect your engine to receive a "force" command from the GUI after every move, then you expect the GUI to implement a different protocol.

[hgm]

If UCI is more popular now than CECP (which remains to be seen; in my experience people that write an original engine usually start in their own command-line mode, and then convert it to CECP because that is so very much simpler to implement than UCI, often requiring nothing more than understanding the 'new' and 'go' command, and prefixing the moves they print with 'move'), it is mainly because between 2001 and 2008, where new features such as hash tables became common in engines, CECP did not evolve to meet these newer demands. So people naturally turned to UCI, which did provide the features they needed.

[JoshPettus]

Someone let me know if they can compile any Xiangqi engines on linux. I'm starting to think I really lucked out with Elephant Eye. All the other ones I could manage to find source code for won't simply compile without some sort of work done, either they are very unfinished, meant for windows, or just complicated as heck requiring boost, and python and what not. Most don't have make files. And either clang or gcc 4.8 i get boat load of errors. I just don't know where to begin with some of these. Perhaps I should put out an open call on a xiangqi forum that there is a GUI on OSX that supports UCCI and Cyclone UCI. Shame the big ones are all in Chinese.

[Evert]

Sjaak plays it, but the last release is Xboard only. The development version has most of the features I want for it though, so should be nearly ready for release. Of course, it may well have UCCI implementation bugs of its own...

[hgm]

There used to be a very nice forum associated with xqbase.com, some 5 years ago. It was all in Chinese of course, but when you got used to the peculiarities of Google translate (e.g. that "to eat the children" means "capture a piece") I managed to have useful interaction with many people there.

But then there was a government crackdown on illegal internet forums, and it had to close down to preempt that. After that I haven't seen anything useful.

I know there is a Tencent-QQ (a Chinese messenger) group where the inner circle of Xiangqi engine authors dwells. They once gave me access to that, but at some point the QQ program started to mess with my computer, loading Gigabytes of data, so I suspected a virus and deleted it.

I am sure an XBoard version of Sjaak would be fine for Joshua's Xiangqi app.

[JoshPettus]

yup I already knew about sjaak. Nice to have another xb engine that can do that.

Thanks H.G. ... I remember seeing that site a while ago, and was looking for it. Figures.