UCI pondering or infinite search

[Evert]

This seems to me like a design flaw of UCI, forcing engine programmers to add hacks and convoluted code for no reason. Am I missing something ?

No, 100% design flaw. I feel pain every time I have to cater for it.

I'm not so sure this is an issue.

The analogue in CECP is what to do in Analyse mode when you reach the end of the iterations. Depending on implementation, you can drop out of analysis mode (wrong), or re-enter the ID loop immediately after leaving it (which will spam the GUI with output because of deep hash hits and may crash it). The correct implementation is to wait for input if the ID loop finishes in Analysis mode.

Of course you never send a move in analysis mode under CECP, and UCI always returns the engine to force-mode after concluding a "go" command.

[Ras]

Suppose further that I have found a mate in 4. I have exhaustively determined that there is no mate in 3. Just return the answer.

So what, you are allowed to print the PV including mate score. It's not as if the user cannot have any feedback here.

[Ras]

Is there a good reason why the engine can't print bestmove upon completion of the ID loop (eg. depth=127 completed) ?

Because for pondering, the GUI then gets a move in a board position that doesn't allow for this move yet, and since the opponent might play something else, the "bestmove" might never become legal. The protocol would acquire additional statefulness because the GUI would have to remember the circumstances on how to interpret that "bestmove". That kind of protocol mess is exactly what UCI tries to minimise.

For infinite mode because infinite actually means infinite unless the user decides to make it finite. Which he will do if he sees a deep PV while the NPS rate drops to zero (should be while the engine is waiting) and no currmove is transmitted. It's not as if the user can't get feedback.

[lucasart]

This seems to me like a design flaw of UCI, forcing engine programmers to add hacks and convoluted code for no reason. Am I missing something ?

No, 100% design flaw. I feel pain every time I have to cater for it.

Thanks Fabien. I'm glad I'm not the only one.

Another annoying design flaw in UCI is the move representation e1g1 for castling when Chess960=false. This is very annoying and forces me to write special case code, where instead I want to write general Chess960 code and have Chess as a (free of extra code) special case:
* When you print the PV you have to play the moves along the PV, you can't just print them w/o playing them. That's because you need to play them to find out if they're castling moves or not. And you need to know that to effect the e1h1->e1g1 correction for printing moves.
* When you parse a "position ... moves ..." command, you need to do some e1g1->e1h1 transformation again when Chess960=false.

I think this is because UCI was designed for Chess, and Chess960 was retro-fitted into it as an after thought.

[hgm]

* When you print the PV you have to play the moves along the PV, you can't just print them w/o playing them. That's because you need to play them to find out if they're castling moves or not. And you need to know that to effect the e1h1->e1g1 correction for printing moves.

That is more a problem of how your engine internally encodes castling moves. If these had unique codes, you could just convert them to e1g1 or e1h1 depending on the setting if UCI_Chess960, without playing anything. And on parsing moves you have to convert the text strings to your internal representation anyway. You cannot avoid at some point to test whether a given move is a castling, so that you know you have to move the Rook as well. Postponing it to in the search is probably the least efficient of all.

[Evert]

True, but it would still be much nicer if you didn't need to distinguish between 960 and orthochess (or rather, GUIs would always implicitly play 960). Note that you can do exactly that under CECP protocol.

[Dann Corbit]

I agree with Michel, I don't see any design flaw. From a protocol point of wiew the UCI protocol is simple and consistent.

If he ask you infinite search, do an infinite search and give back bestmove only after stop command.
If he ask you to ponder, don't give back a bestmove.... because it's not your turn.
If he ask you some time/node/depth bounded search return bestmove ad soon as you hit the limit or after a stop command.
If it ask you to act like a player playing a game, the engine can manage the time by himself and reply with bestmove when he want. Before or after time expiration.

Where is the flaw?

I have millions and millions of positions I want to analyze.
Some batch of thousands might analyze 60% faster if the engine spit out the answer when it knew it could not improve it.
That's stupid. Or a broken specification. Or both.

I have some dozen positions I want to analyze deeply. The time is set at 8 hours per position. If 3 of them are completely solved in an hour, so that there can be no improvement, that is 21 hours wasted on those three positions, just sitting there doing nothing and not going on to the next.

Now, there are some engines that do spit out the answer. I love them for that. And I thank the authors on my hands and knees for doing the right thing instead of following the broken specification.

[Dann Corbit]

Suppose further that I have found a mate in 4. I have exhaustively determined that there is no mate in 3. Just return the answer.

So what, you are allowed to print the PV including mate score. It's not as if the user cannot have any feedback here.

I run analysis in batches of positions.

I do not want it to spit out the answer and then sit there doing nothing. I want it to go in to the next position.

The specification is both broken and stupid for what I want to do. I do realize that I am the narrow exception and therefore do not matter and the broken specification (FOR ME) will never be fixed.

Why is the GUI in command when the GUI is an arse?

[Ras]

I run analysis in batches of positions.

I do not want it to spit out the answer and then sit there doing nothing. I want it to go in to the next position.

You can just do that. If the returned score in the PV is above/below a certain threshold, regard the position as solved, send the stop command and proceed with the next position.

Or you could use wtime/btime as 8 hours and set movestogo to 1.

UCI isn't at fault for deficiencies of the batch tool.

[hgm]

Exactly. Infinite analysis is exactly that: go on until the command is revoked, no matter how long it takes. If you want to analyze for 8 hours, you should not use go-infinite, but go-8-hours, just like Rasmus says. Then it is the engine's decision when to spit out a move, and it could do (and probably would do) all the things you wish.

If you run an EPD testsuite in XBoard, you can set it to any TC you like. You can use fixed time per move, or just specify an average time through a classical TC.