Trick stockfish into outputting longer lines

[ornicar]

I don't dare asking for that in a stockfish repo, since it's really for lichess.

Since version 8 or even before, SF outputs many very short variations of one or two moves. Regardless of the depth reached.

Exemple: https://en.lichess.org/jNsrRl4a. But really it can be seen on every analysis.

There must be good reason for the short lines. Maybe the missing moves were not considered good enough, I don't know.

But it doesn't look very good in the lichess analysis. Actually I saw many players believe that it was an indication of short search depth. A variation of 2 moves may look, to some, like a search depth of 2 plies.

If there was a simple enough way to make stockfish spit at least 10 moves long variations, it'd be neat.

[Vinvin20]

It's probably related to this : https://groups.google.com/forum/?fromgroups=#!searchin/fishcooking/pv$20from$20hashtable%7Csort:relevance/fishcooking/jFKq-aKJOu0/qsUY6wQK4mIJ

[Vinvin20]

Another idea : when the PV is short, get the latest (previous depths) long PV.

[ddugovic]

This summary sounds accurate:

This is the history:

Glaurung had accurate pv's and did not probe at pv nodes.

The pv's were replaced by TT pv's (simplification?).

Probing at pv nodes was enabled (simplification?).

The TT pv's were replaced again by accurate pv's and probing at pv nodes was again disabled.

So it seems we have now come full circle :-)

I wonder, how difficult would it be to add a pv [moves ...] command to Stockfish? For example, if from the start position Stockfish output:

info depth 2 score cp 214 time 1242 nodes 2124 nps 34928 pv e2e4 e7e5 g1f3
bestmove e2e4

I would want to be able to issue pv moves e2e4 e7e5 g1f3 to extract something (such as the next move) from the transposition table.

[lakinwecker]

There is a branch here: niklasf/Stockfish#1 that will get us a short term solution. I'm working on a longer term solution and will update this issue once I have made progress.

[lakinwecker]

Work started on the pv moves command in this PR ddugovic/Stockfish#180

[lakinwecker]

As discussed on the pv moves command PR, the Transposition Table does not contain a PV. Extracting moves out of it is technically straightforward, but they do not (and probably never did) represent a PV. Fundamentally, it seems that Stockfish does not calculate a PV during it's move search. Sometimes it ends up with one, but not always. When it doesn't we end up with short PVs and there is (probably) no way to extract them from current data structures.

The approach captured in ddugovic/Stockfish#179 is probably the best we have without changing stockfish to use a different search pattern that guarantees the production of a PV.

I'm happy to keep poking at it if people think there are alternative solutions, but at this point I have no other ideas.

[ddugovic]

Sorry for my delay in reviewing & merging that PR; I'm in the middle of:

• fixing/testing Antichess qsearch ddugovic/Stockfish#70
• testing improvements to ddugovic/spsa (Stockfish parameter-tuning)
• merging upstream changes

and hope to have all that plus this merged in the next day.

[lakinwecker]

No worries. You mentioned something about a compile time guard for this so that you could more easily keep this up to date with the main Stockfish repos more easily. If you'd like me to do any of that work, let me know. I'm happy to do it for you to take work off of your plate.

[ddugovic]

Ah, right... I'll code review (using GitHub code review capability).

[lakinwecker]

w00t. The stockfish patch was merged. \o/ Thanks for your help ddugovic!

[niklasf]

Also released for fishnet, client side eval updated.

[ornicar]

The situation is now better, but not yet fully solved. I just requested an analysis on https://en.lichess.org/bqfZx13X and:

[niklasf]

Related: ddugovic/Stockfish#547

[stale]

There has been no activity on this issue for 2 years. It will be automatically closed in 2 weeks.
If the issue is still relevant, please briefly explain (or remove the label). Feel free to reopen at any time.

[Dboingue]

This should be reopened.. SF has fixed the problem now. All GUI talking to SF can get its full PV length now.
If not this one, a related one about Truncated PV display by lichess. I remember one closed after pointing to an issue in SF as argument. But that issue is moot now: SF does give out its full length PV. fixed. This is really annoying to have that old lichess capping as engine keep looking deeper and deeper... this is a mystifying enabler for use of SF as analytic tool (half-baked one).

[ornicar]

Lichess doesn't cap and we use the latest stockfish

[Dboingue]

Lichess doesn't cap and we use the latest stockfish

Thank you for reading that comment. as previous poster kindly mentioned, I did make a new request in case here would not be read. I understand that i need either to revise what capping means, or make screenshots using FENs of 22 or 23+ chrome browser PV displays. And show the same with command line, where the full depth PV main variation would be shown.
Maybe i did not try, lately. When was the cap taken off? or perhaps it is a hidden non-intended cap, from the modules handling SF output down to the user display. A dev has tried to give it the maximum user friendliness last year. (kudos). But it could not invent full length PVs. I can find the lichess discussion.. it has lots of issues being linked inside.. to support the understanding i have here, and in the new issue. I will start building the case with such links in the new issue.. without my words to bury them for a while...