Stockfish > 16 ignores setoption after go about stockfish HOT 18 CLOSED

Can the wait_for_search_finished() statement explain why no further uci commands (like stop or quit) are executed after once setoption has been called?

Well yes that’s why I posted it..
And there is no expected behavior according to the uci protocol really, every engine is free to interpret this like it wants to.

from stockfish.

I don't think we should do this, consider it was working by accident, now it is consistent with e.g. Hash as pointed out.

from stockfish.

https://xkcd.com/1172/

from stockfish.

@cernst72 btw I just checked the code of sf 15.1. Turns out what I suspected earlier is true.

I think the setting for the multipv is saved after starting the search and only the output you get is read dynamically from the options.

So basically your workflow was/is flawed even with old stockfish versions. You are only reducing the output to the terminal, which is basically useless imo.

from stockfish.

I don't understand your reproduction are trying to modify the options while a search is ongoing?

from stockfish.

This behaviour isn't really something one should do/rely on.

https://backscattering.de/chess/uci/

One string will be sent for each parameter and this will only be sent when the engine is waiting

The engine isn't really in a waiting state after you wrote go ...,
but the behavior was indeed changed (unintentionally) ... this was not there before https://github.com/official-stockfish/Stockfish/blob/master/src/uci.cpp#L314.

from stockfish.

That behaviour was even (more or less) present before for the options Hash and Clear, so right now it is arguably more consistent.

from stockfish.

I don't understand your reproduction are trying to modify the options while a search is ongoing?

Yes, this is indeed what I want to. It worked up to SF 15.1 and it still does work in Dragon and LC0.
Can the wait_for_search_finished() statement explain why no further uci commands (like stop or quit) are executed after once setoption has been called?

from stockfish.

Agree. This "expectation" cannot be derived from the uci protocol.
As a user I like the feature to adjust the pv, which is present in former Stockfish versions and other engines, very much and would be glad if it could be maintained by Stockfish again.

from stockfish.

Can the wait_for_search_finished() statement explain why no further uci commands (like stop or quit) are executed after once setoption has been called?

https://backscattering.de/chess/uci/

the engine must always be able to process input from stdin, even while thinking.
if the engine receives a command which is not supposed to come, for example stop when the engine is not calculating, it should also just ignore it.

Am I misunderstanding the specification? Is setoption considered a command which is not supposed to be issued immediately after a go? Is the setoption being ignored, or is it breaking the processing of input from stdin while thinking? Under what circumstances should stop not actually stop thinking?

from stockfish.

Yeah.. I think the blocking stdin is not ideal, we should probably ignore the setoptions all while searching, instead of stopping search.

from stockfish.

it is just a mistake of the user / GUI to send setoption if the search is ongoing. The search is ongoing if it has been started with a go, for as long as bestmove hasn't been returned.

from stockfish.

Sorry, removed post because i haven't overlooked Disservin citation of UCI specs

from stockfish.

I'am personnaly have no preference between old and new behavior, but technically SF implements the UCI protocol more correct.

from stockfish.

As a user I still want to be able to interact with a very long (> 1 h) search like letting it run with multiple pv for a few minutes then narrowing the search to the top 1 or 2 pvs.

I understand that you don't want to support go, setoption, setoption ....
But, as RogerThiede and Disservin pointed out, the way you do this is not conforming to the protocol either.
Of course, once a user has understood his "mistake" (calling setoption after go) he will probably not try it again, so not much worry.
(But still, why do you need to block yourself and your users, instead of being generous and allowing users to play with setoption and see what they get? Yes, because the protocol says so.)

The alternative way, position, go, stop, setoption, go, is not easy going with Stockfish 16.1 too: The second go does not resume from your position, but the search starts over from startpos.
So you more or less have to start from scratch after stop.

Can you recommend a way to reduce the pv of a long-running search?

from stockfish.

Wdym the second go doesn’t resume from your position? It should (but can’t test right now).

Which gui are you evening using ? We had a look at a few GUIs and they all anyway send stop before iirc.

Why would you want to reduce the pv? Or do you mean multiPV?

I think what you even did in the past never even really worked. I think the setting for the multipv is saved after starting the search and only the output you get is read dynamically from the options. Which means multipv was still running with the same setting as it did before only what you visually see has changed.

from stockfish.

Wdym the second go doesn’t resume from your position? It should (but can’t test right now).

Oh, yes it does. I tested on the console, but made a mistake when entering the position command (omitting "fen"). Sorry for this confusion.
I begin to understand, that I will have to adjust my workflow. So feel free to close this issue.

from stockfish.

Yes. I should stop() before calling setoption(). Thank you, Disservin, for looking at it!

from stockfish.