some UCI protocol issues/questions

[jdart]

Point taken. My engine has a "test" command for EPD analysis, which exits right away on mates or TB hits. So I don't ever see this issue.

--Jon

[CThinker]

Then not just Fruit, but a lot of Fruit variants, are broken in analysis mode. Unless I misread the source.

--Jon

Sorry there is a misunderstanding. Sending a "bestmove" is infinite analysis mode is a protocol violation. As far as I know Fruit handles this correctly (i.e. it does NOT send a bestmove).

Even if the engine detects a mate in one it should not return from the search but instead go into some kind of delay loop until "stop" is received.

Something for both Winboard and UCI protocols that is missing:
Engine says:
DONE: Bxc4 Nxc4#

What I mean by this is that if the engine has proven to its own liking that there is no better move possible, it should inform the GUI.

What is an engine doing slogging along in an 80 ply search when it found a mate in 4?

It is a very, very irritating waste of time when an engine has solved a position and yet (because there is not any clear "I'm DONE now" signal, it must search again and again, proving to itself what it already knows.

I have never seen this issue with Winboard engines.

Here is an example using Crafty. Notice how there is search progress when analyzing from the initial chess position. But with mate positions, Crafty simply stops searching (no CPU usage).

Code: Select all

C:\crafty-23.4-win32.exe
EPD Kit revision date: 1996.04.21
unable to open book file [./book.bin].
book is disabled
unable to open book file [./books.bin].

Initializing multiple threads.
System is SMP, not NUMA.

Crafty v23.4 PS (1 cpus)

White(1): xboard

tellicsnoalias set 1 Crafty v23.4 PS (1 cpus)
tellicsnoalias kibitz Hello from Crafty v23.4 PS! (1 cpus)
post
analyze
Analyze Mode: type "exit" to terminate.
        13     14      82 399570  1. Nc3 Nc6 2. Nf3 Nf6 3. e4 e6 4. Bb5 Bb4 5. O-O O-O 6. d3 d5 7. Bd2 Bxc3 8.
 Bxc3 dxe4 9. Bxc6 bxc6
        13     14     103 506469  1. Nc3 Nc6 2. Nf3 Nf6 3. e4 e6 4. Bb5 Bb4 5. O-O O-O 6. d3 d5 7. Bd2 Bxc3 8.
 Bxc3 dxe4 9. Bxc6 bxc6
        14     23     149 759902  1. Nc3 Nc6 2. Nf3 Nf6 3. e4 e5 4. d4 exd4 5. Nxd4 Bc5 6. Nxc6 bxc6 7. e5 Qe7

        14     23     188 951713  1. Nc3 Nc6 2. Nf3 Nf6 3. e4 e5 4. d4 exd4 5. Nxd4 Bc5 6. Nxc6 bxc6 7. e5 Qe7

        15     38     273 1358286  1. Nc3 Nc6 2. Nf3 Nf6 3. e4 e5 4. d4 exd4 5. Nxd4 Bb4 6. Nxc6 Bxc3+ 7. bxc3
 dxc6 8. Qxd8+ Kxd8
        15     38     296 1492341  1. Nc3 Nc6 2. Nf3 Nf6 3. e4 e5 4. d4 exd4 5. Nxd4 Bb4 6. Nxc6 Bxc3+ 7. bxc3
 dxc6 8. Qxd8+ Kxd8
        16     15     605 3114902  1. Nc3 Nc6 2. Nf3 Nf6 3. e4 e5 4. d4 exd4 5. Nxd4 Bb4 6. Nxc6 Bxc3+ 7. bxc3
 bxc6 8. e5 Ne4
        16     15     998 5060580  1. Nc3 Nc6 2. Nf3 Nf6 3. e4 e5 4. d4 exd4 5. Nxd4 Bb4 6. Nxc6 Bxc3+ 7. bxc3
 bxc6 8. e5 Ne4
        17     17    1212 6145297  1. Nc3 Nc6 2. Nf3 Nf6 3. e4 e5 4. d4 exd4 5. Nxd4 Bb4 6. Nxc6 Bxc3+ 7. bxc3
 bxc6 8. e5 Ne4 9. Qd4
setboard 2k5/8/3K4/4Q3/8/8/8/8 w - - 0 1
         4  32764       0   7101  1. Qb5 Kd8 2. Qb8#
setboard 2k5/rp6/3K4/3RQ3/8/8/8/8 w - - 0 1
         4  32766       0   1459  1. Qe8#
setboard rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
        17     17     690 4034267  1. Nc3 Nc6 2. Nf3 Nf6 3. e4 e5 4. d4 exd4 5. Nxd4 Bb4 6. Nxc6 Bxc3+ 7. bxc3
 bxc6 8. e5 Ne4 9. Qd4
        18     13    1855 10333480  1. Nc3 Nc6 2. Nf3 Nf6 3. e4 e5 4. d4 exd4 5. Nxd4 Bc5 6. Nxc6 bxc6 7. e5 Q
e7 8. Bf4 Rb8 9. Be2 Nd5 10. Nxd5 cxd5
        18     13    3286 18160846  1. Nc3 Nc6 2. Nf3 Nf6 3. e4 e5 4. d4 exd4 5. Nxd4 Bc5 6. Nxc6 bxc6 7. e5 Q
e7 8. Bf4 Rb8 9. Be2 Nd5 10. Nxd5 cxd5

[John Major]

But then after stop - it should do nothing?

It should just return "bestmove".

stop should _always_ be followed by bestmove (if the engine has been given a search command). Even if the bestmove is useless (e.g. after a ponder miss).

This predictability ensures that UCI does not need a ping equivalent to avoid race conditions (isready is not to avoid race conditions).

Don't you mean deadlock condition, where engine and interface are waiting for each other?

[Gian-Carlo Pascutto]

I often will take a list of 150 positions, and let a very strong engine analyze at (for instance) 1/2 hour per position over the weekend. It will often be the case that ten hours or so is completely wasted because of sitting there doing nothing for 20 of the positions.

I don't get it. Why not use a timecontrol? If you're using infinite analysis, you get exactly what you ask for.

[Gian-Carlo Pascutto]

Don't you mean deadlock condition, where engine and interface are waiting for each other?

No. (I guess a race condition could cause a deadlock, though, but lets not mix cause and effect)

[Gian-Carlo Pascutto]

"* if the engine or the GUI receives an unknown command or token it should just ignore it and try to parse the rest of the string.")

Now THERE is a wonderful specification. use what you understand, ignore what you don't, and if the results are worthless, who knows?

The GUI can know if it probes capabilities (which it can do, because the probing commands will be ignored if not understood)

Quite similar to things like reserved flags in the TCP/IP suite. I think that's a design that held up well, so your unargumented criticism is baseless.

[Gian-Carlo Pascutto]

Because it only sends the move list to the engine, it is also very hard for the engine to keep track of where it is in the game.

You can't tell where you are in the game from the movelist??

[hgm]

Like many other things, it is a big deal for me and for almost nobody else on the planet.

I often will take a list of 150 positions, and let a very strong engine analyze at (for instance) 1/2 hour per position over the weekend. It will often be the case that ten hours or so is completely wasted because of sitting there doing nothing for 20 of the positions.

It is especially true when analyzing a large segment of endgame positions.

It probably bothers nobody else at all, but it bugs me to no end.

It seems to me that you bring this upon yourself. If you want to do not exactly 1/2 hour per position, but 1/2 hour maximum, you should use the engine not in analysis, but in fixed-max-time-per-move mode (st in WB, movetime in UCI). Then the engine will terminate the search if there is nothing left to search.

[hgm]

I have never seen this issue with Winboard engines.

Here is an example using Crafty. Notice how there is search progress when analyzing from the initial chess position. But with mate positions, Crafty simply stops searching (no CPU usage).

Not all engines are as smart as Crafty, however. Micro-Max would seach to d=100, which would still take only an instant if mate-in-3 is looming, since it doesn mate-distance pruning, and all d>5 searches will be as fast as the d=5 search. But there are engines that do not even do mate-distance pruning, and they search for minutes even on mate-in-1 positions.

[bob]

"* if the engine or the GUI receives an unknown command or token it should just ignore it and try to parse the rest of the string.")

Now THERE is a wonderful specification. use what you understand, ignore what you don't, and if the results are worthless, who knows?

The GUI can know if it probes capabilities (which it can do, because the probing commands will be ignored if not understood)

Quite similar to things like reserved flags in the TCP/IP suite. I think that's a design that held up well, so your unargumented criticism is baseless.

No it is not "baseless". If you ignore a token, you take a step down a slippery slope since the next token might depend on the context of the previous one. Before long, you are running hell-bent down a steep slope with no hope of stopping until you crash into something.

One doesn't "ignore" flags in TCP/IP. So I am not sure what that is about. You don't have to use any/all of the flags if you don't want to. Unless you are talking about the real "reserved" flags that have _no_ explicit meaning. Not sure how that applies to this circumstance...

A protocol should be specific. If it has optional pieces, that's fine (as in xboard protocol). But to just "ignore than which you don't recognize/understand?" Wars have been started over less.