Break from aspiration window loop when Signals.stop is true only after outputting pv info dump #20

Closed
wants to merge 2 commits into
from

Conversation

Projects
None yet
3 participants

tpsinnem commented Aug 4, 2012

[Edited in a new lead paragraph because otherwise it was confusing]

Hello!

I noticed that the final iteration of the aspiration window loop produces no uci pv output. I made this change in case there is not some existing reason why that information should not be posted.

I noticed this thing when experimenting with nodes limits -- from reading the code, I got the impression that node limits would usually be exceeded, and only then would the search stop and the final info be reported. However in the stockfish uci output the nodes count was (nearly) always under the limit.

I did note, afterwards, that the Search Log does get the final info but it would be nice to have it in the uci dump as well, if there's no obstacle.

Cheers!

tpsinnem commented Aug 4, 2012

Also, I suppose my above comment may give the impression that the nodes limit being exceeded was a problem, but for me at least it isn't, at least in the single-threaded case. Just a side note :)

ornicar commented Aug 4, 2012

👍

Owner

mcostalba commented Aug 7, 2012

On Saturday, August 4, 2012, tsinnema <
reply@reply.github.com>
wrote:

Hello!

I noticed this thing when experimenting with nodes limits -- from reading
the code, I got the impression that node limits would usually be exceeded,
and only then would the search stop and the final info be reported. However
in the stockfish uci output the nodes count was (nearly) always under the
limit.

I made this change in case there is not an existing reason why the uci pv
dump from the final iteration should not be posted.

I did note, afterwards, that the Search Log does get the final info but
it would be nice to have it in the uci dump as well, if there's no obstacle.

Cheers!

You can merge this Pull Request by running:

git pull https://github.com/tsinnema/Stockfish aspWindowOutput

Or you can view, comment on it, or merge it online at:

#20

-- Commit Summary --

  • break from aspiration window loop on Signals.stop only after outputting
    pv info dump
  • removed worry comment

-- File Changes --

M src/search.cpp (10)

-- Patch Links --

https://github.com/mcostalba/Stockfish/pull/20.patch
https://github.com/mcostalba/Stockfish/pull/20.diff


Reply to this email directly or view it on GitHub:
#20

Hi,

Thanks for your patch but I'd say it is not correct. When search gets a
stop signal (there are many causes for this, not only node count reached),
it immedeately stops the search And returns and so the information in th PV
line is normally totally untrustable and invalid, this is the reason why it
is not sent to GUI in case we have been stopped.

tpsinnem commented Aug 7, 2012

Thanks for the response!

Is it not the case, though, that the move decision (i.e. 'bestmove' output) is made based on the same info that uci_pv would have in the final AW loop iteration, if it was called? It would seem to me that cases with Signals.stop (whether from the outside, or via node limits etc.) are imperfect whichever way you go; in the unpatched stockfish, I can get cases like this (this is from a chess960 position btw, though I don't think it matters), where the bestmove and the first reported pv move don't agree:

info depth 11 seldepth 3 score cp 32 nodes 3993 nps 137689 time 29 multipv 1 pv e4e2 g7f7 c4d5 e6d5 a3c3 d8c8 b4d3 f6f3 e2f3 f7f3 e1e7 c7d6
stop
bestmove c4d5 ponder e6d5

I would think this is a problem?

tpsinnem commented Aug 7, 2012

That, btw was of course an example where I triggered Signals.stop myself, but this move report disagreement also happens with time or node limit checks being triggered, and I think that's worse, since in the case with the user interaction, it's at least clear that the search was indeed interrupted, which would hopefully make the discrepancy less alarming to the user.

tpsinnem commented Aug 7, 2012

On a completely different note, I had made edits to the original message because I realized it was unclear, and I'm guessing that a) Github doesn't send those edits as follow-ups through the any e-mail interface and that b) you are responding through such an e-mail interface. If it's no trouble, I hope my intent is more clear if you'll read it on Github! :)

mcostalba closed this Aug 31, 2015

@alwey alwey pushed a commit to alwey/Stockfish that referenced this pull request Nov 23, 2016

@ddugovic ddugovic Merged comment fixes #20 32d2f1d

@alwey alwey pushed a commit to alwey/Stockfish that referenced this pull request Nov 23, 2016

@ddugovic ddugovic Merge branch 'Unihedro-patch-1' fixes #20 efaa7a6
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment