UCI protocol: giving up!

[hgm]

Also your program will benefit from the book of the GUI. One of the many advantages of UCI vs Xboard

???

I guess you mean: one of the many lies spread spead by proponents of a flaky and inefficient protocol to trick people into using it.

Whether programs use GUI book is of course a matter of GUI implementation, and has absolutely nothing to do with what protocol is used to communicate with the engine, as in this case the GUI is playing from the book, and the engine is not even involved...

That of course raises the question of all the other things you said where dis-info too...

Fact is that to make an UCI engine work automatically for playing test games, you minimally need the commands:

position
moves
go
wtime
btime
winc
binc
movestogo
ready
uci

bestmove
readyok
uciok

To make an engine work in XBoar protocol, you only would have needed
new
force
go
time
level

move

Simple counting will reveal what is easier...

[mar]

Gentlemen please

Although I prefer UCI it would be fair to say that xboard has actually many advantages over UCI I prefer UCI simply because I find it lightweight compared to xboard.

UCI:
+ lightweight (the price to pay is that this makes UCI not too versatile)
+ mate scores
- too verbose, very high I/O traffic from both engine and GUI can cause problems in super-fast matches
- no draw offers
- no ICS commands

XBoard
+ much more general
+ native support for variants
+ engine can display it's own PV strings
+ very little I/O overhead
+ much more freedom
- a bit complex and clumsy due to all the extensions based on how it evolve over the years


To summarize: xboard is a true protocol while UCI is more or less a bridge between the GUI and the engine.

I am sure I forgot some things

To summarize: neither is perfect, it's just a matter of TASTE.

[hgm]

True, but it is not a matter of taste whether WinBoard engines can use GUI book or not... That is hard fact.

I am not sure about the lightweight part, though. How do you define 'lightweight'? The minimal subset of commands needed to get a usable engine is only about half 10/3 for UCI (GUI->engine/Engine->GUI), and only 5/1 for XBoard, as I have already shown above. Even with full implementation of both protocols, I doubt you really would need more different commands / keywords for XBoard than for UCI.

So I always advice beginning engine developers to adapt their engine (usually using a 'home-built' protocol at that time) to convert it to XBoard, because it is so much less work for them.

[mar]

True, but it is not a matter of taste whether WinBoard engines can use GUI book or not... That is hard fact.

I am not sure about the lightweight part, though. How do you define 'lightweight'? The minimal subset of commands needed to get a usable engine is only about half 10/3 for UCI (GUI->engine/Engine->GUI), and only 5/1 for XBoard, as I have already shown above. Even with full implementation of both protocols, I doubt you really would need more different commands / keywords for XBoard than for UCI.

So I always advice beginning engine developers to adapt their engine (usually using a 'home-built' protocol at that time) to convert it to XBoard, because it is so much less work for them.

Well using GUI book is a nice feature but it can be configured in UCI-capable GUI when the engine has no book. So not a big deal I think.

By lightweight I meant you don't have to worry about a lot of things, you don't have to worry about backing up moves, doing pondering all by yourself and so on. The price you pay for XBoard flexibility. UCI has only a very little subset of commands. XBoard has much more. That is a fact
So I think a full implementation of XBoard wil require more code IMO.
Let's make a deal: I will implement full XBoard protocol in the next version and you implement native UCI support in next GUI Fonzy probably won't be happy though.

Martin

[lucasart]

True, but it is not a matter of taste whether WinBoard engines can use GUI book or not... That is hard fact.

I am not sure about the lightweight part, though. How do you define 'lightweight'? The minimal subset of commands needed to get a usable engine is only about half 10/3 for UCI (GUI->engine/Engine->GUI), and only 5/1 for XBoard, as I have already shown above. Even with full implementation of both protocols, I doubt you really would need more different commands / keywords for XBoard than for UCI.

So I always advice beginning engine developers to adapt their engine (usually using a 'home-built' protocol at that time) to convert it to XBoard, because it is so much less work for them.

How do you set the hash size of an xboard engine ? I mean by an option that is xboard standard and will be the same for all xboard engines ? the pondering (on/off) ? the number of threads ?

[hgm]

UCI has only a very little subset of commands. XBoard has much more. That is a fact

This is exactly what I am doubting. Have you really counted them? I think you would be surprised if it was in fact not the other way around. UCI is extremely verbose, and you need commands for almost everything which is simply implied in WB protool. There are for instance no equivalents to 'mate', 'cp', 'score', 'pv', 'currentmove', etc. My estimate is that UCI needs about twice the number of commands of WB protocol.

Let's make a deal: I will implement full XBoard protocol in the next version and you implement native UCI support in next GUI Fonzy probably won't be happy though.

I don't think that is a good deal. We should not let all user's suffer, just to improve your engine...

[lucasart]

True, but it is not a matter of taste whether WinBoard engines can use GUI book or not... That is hard fact.

I am not sure about the lightweight part, though. How do you define 'lightweight'? The minimal subset of commands needed to get a usable engine is only about half 10/3 for UCI (GUI->engine/Engine->GUI), and only 5/1 for XBoard, as I have already shown above. Even with full implementation of both protocols, I doubt you really would need more different commands / keywords for XBoard than for UCI.

So I always advice beginning engine developers to adapt their engine (usually using a 'home-built' protocol at that time) to convert it to XBoard, because it is so much less work for them.

Well I wouldn't agree xboard is less work either. Let's say that xboard and uci are both as simple to implement (in your "counting" you're counting parts of the same command on the UCI side, but we all know you're biaised )
And let's even agree that xboard has more functionality than UCI.

In reality, that's not what matters to me. I want the protocol to standardize things. And that's where xboard is an abortion
For example if i want to set the hash size of an UCI engine to 64 and set pondering to false:

Code: Select all

setoption name Hash value 64
setoption name Ponder value false

xboard ? well because xboard is so amazingly flexible, everyone does it differently... and a lot of people use a config file, sometimes even with a hardcoded file path in the program executable (like c:\windoard\config.ini, woat that helps me a lot using linux...)
some use options via xboard protocol, but nothing is standardized. so i want to do automated engine matches, playing lots of different ones in a script file via cutechess-cli, and everytime i have xboard ones in there, it's a pain in the a..

But the day they decide to standardize things in the xboard protocol properly, then I will stop hating it, and I might even come to prefer it to UCI (I agree about the heavy traffic in UCI)

[mar]

UCI has only a very little subset of commands. XBoard has much more. That is a fact

This is exactly what I am doubting. Have you really counted them? I think you would be surprised if it was in fact not the other way around. UCI is extremely verbose, and you need commands for almost everything which is simply implied in WB protool. There are for instance no equivalents to 'mate', 'cp', 'score', 'pv', 'currentmove', etc. My estimate is that UCI needs about twice the number of commands of WB protocol.

Let's make a deal: I will implement full XBoard protocol in the next version and you implement native UCI support in next GUI Fonzy probably won't be happy though.

I don't think that is a good deal. We should not let all user's suffer, just to improve your engine...

Well I count UCI's info as one command
Ok but I am tempted to try full xboard anyway. I hope it won't add many bugs though

Martin

[hgm]

Well I count UCI's info as one command

Yeah,by cheating with counting it is of course always possible to prove anything. No doubt you probably also count

position startpos moves e2e4 e7e5 g1f3 b8c6 f1c4 f8c5 b1c3

and

go ponder wtime 300 btime 300 winc 1 binc 1

each as one command. Well, by that way of counting WB protocol only has a single command: the entire game. Difference with UCI is that you only have to send that command once, rather than every move.

But this cannot hide the fact that a UCI engine or GUI would have to decode all those keywords, so it can take the actions they specify. So that in the end you will need more code to implement the UCI driver than an equally capable WB-protocol driver.

[mar]

Well I count UCI's info as one command

Yeah,by cheating with counting it is of course always possible to prove anything. No doubt you probably also count

position startpos moves e2e4 e7e5 g1f3 b8c6 f1c4 f8c5 b1c3

and

go ponder wtime 300 btime 300 winc 1 binc 1

each as one command. Well, by that way of counting WB protocol only has a single command: the entire game. Difference with UCI is that you only have to send that command once, rather than every move.

But this cannot hide the fact that a UCI engine or GUI would have to decode all those keywords, so it can take the actions they specify. So that in the end you will need more code to implement the UCI driver than an equally capable WB-protocol driver.

Position and go are different. As I already said UCI is too verbose and we basically agree on that topic. But neither protocol is perfect.
Anyway I'll be able to compare myself once I implement xboard protocol (if i ever get time to do so)

Martin