Give us all the SF main PV plies. To include the evaluated leaf position.

[Dboingue]

1. There was once a problem with SF not giving the full depth of the PVs in its output.
2. Lichess has tried to compensate for that, or kept a status quo, with some cap below 16**.
3. With all the space available for many PVs, and that the lines are collapsible:

- I hereby ask that lichess gives us all the plyes or plies be it 22, 23, or more, not 16, or less, as is now the usual case.

We should be able to see the leaf position that gave a score we read in any engine analysis output.

There were related issues in the past, but they ultimately relied on the SF issue which was fixed. Long story. SF now gives it all.

**and sometimes less, not always about transposition table, as even many PV setting would adopt the same cap, which would be unlikely SF search results.

[benediktwerner]

I don't think the SF issue you're describing (#2423) has anything to do with the cap in the UI. One was about showing more, the other is about showing less.

pvs are currently capped at 16: https://github.com/lichess-org/lila/blob/master/ui/ceval/src/view.ts#L388

Long pvs eventually get quite inaccurate though and it does clutter the UI so not sure how much sense increasing or removing the limit makes.

[Dboingue]

puzzle starting position. 1WR5U

using the puzzle source game FEN and putting in analysis:
6k1/7p/2q1r3/p1P2r2/P1Q5/5PP1/7P/5RK1_w_-_-_7_36

I still get less than 16 or 16. It could still be transposition table for shorter than 16 and I do not see the old behavior of all 3 PVs having the same cut off as last year. But what we see with the extra ply in the solo analysis tool (not in puzzle context, with its own parameters), That the PV has changed with deeper input depth AND that the PV display depth, there, did not budge.

Those observations alone are not enough to show the possible capping at user end of using lichess interface with SF executable used. I Need another equivalent experiment such as command line SF for info output with full PV length, where we can control the hash table too. That is WIP.

However, this has been done last year, as can be read in the following posts from lichess forum,
that contain source code pointers hypotheses on lila side.
https://lichess.org/forum/lichess-feedback/full-pv-dumpdisplay-for-any-engine-analysis?page=4#35
https://lichess.org/forum/lichess-feedback/full-pv-dumpdisplay-for-any-engine-analysis?page=4#38

Todos

• SF command line with above FEN, for info output of full PVs. (cache perturbation experiments).
• find out lichess cache parameters to reproduce in command line (overdoing it?)
• Can the browser executables be accessed command line with same UCI interface?
• Using Liground instead of the above (own post, later for SF12, mutli-variant SF, and Fairy-SF)

The last entry is WIP. see last comment for more. The software repository refers to libraries from lichess and chessground, in the readme file. The interface does not seem completed in terms of saving local files. The log can be copy pasted. And I can join screenshots to show the PV lengths exhibited in the PV box. Using SF12 does not matter, the question is about getting the leaf position at the source of the root score for any analysis. Trying the other engines, too, just to see if they also show Full PV.

[schlawg]

Getting off track here. Giving the full PV to the user is possible (though I believe that additional information is completely useless). It can't hurt anything except steal 15ish pixels per expanded PV from the move list, so maybe we should just label this "Good First Issue" and let someone do it. Then thibault could either merge it or not.

[Dboingue]

Not a bug, but a real improvement suggestion for the lichess users doing engine analysis routinely and even talking about the root score, never really seeing the position that gave those values at the basis of their chess analysis and discussions.

Help. How does one add a label of "improvement" to an issue? If this is in my jurisdiction as non contributor and visitor.
Also additional simple questions reversing burden of rationality or demonstration. @benediktwerner among others and other non-posting repliers.

why 16? why not 10. why not 5.
why even put a collapsible user feature in the UI? with 5 or 10, if might all fit on one line.
why put any PV at all beyond what seems to be the only bit of output this status quo seems to imply, as well as second post:
the leftmost node of the PV. why not just put those only worthy nodes on one line to save the UI.

why even display the score of the PV, if what only matters is the "accuracy" for the move candidate found best after the long inaccurate tree search (where does the inaccuracy creep in, exactly?). The TT keeps all recent evaluations. I would hope it would still have the hash of the position that gave the score value. If that is inaccurate. why clutter the display with root position score?

There are real questions. I would like someone to give a try to answering them. It might either unclog some sinuses. or make me understand the common sense if any behind post #2, second sentence unsupported opinions, as can be read here.

[Dboingue]

Liground interface.
https://raw.githubusercontent.com/LucyLMM/images/main/LiGround_Screenshot.PNG

Please consider the right hand side. I will use this software, which is in part based on lichess codebase, to show that no it is possible to not have that mystifying cap put at 16.
Wiki seems to exist:
https://github.com/ml-research/liground/wiki
It explains the software model. of note:
PVLines and
EngineConsole
There is a complete component tree.
They mention having been inspired by lichess analysis code source on the readme page.

• SF12 with above puzzle FEN
• Multivariant SF (came with liground, version 10)
• Fairy SF (idem, 13)

6k1/7p/2q1r3/p1P2r2/P1Q5/5PP1/7P/5RK1_w_-_-_7_36

[Dboingue]

Liground. journalling WIP. problem in analysis mode. it does go depth infinite.
ml-research/liground#249 (comment)

,,, In the meantime you can use the command line box and type go depth if you want to get an analysis for a certain depth.

that box is under the engine log output (info) console. UCI talking. so i can do go depth 20.. that should be enough proof of concept based on software referring to lichess modules. Perhaps they PV display code is not.

In liground, when choosing SF12 I get the following credits:

"Stockfish 2020-06-13 64 Multi-Variant" by D. Dugovic, F. Fichter et al.

So I wonder what the other engine names multivariant might be: Answer same authors older version. scratch that (unless it shows some PV printout evolution.

Finally maybe bad idea... this liground. although the UCI console shows that even those version output long PVs.
Might want to download the real SF14.. to be on par with previous post... but at least that is a SF12 version

the other is "Fairy-Stockfish 13 LB" by Fabian Fichter.

I am confused as to which of those is lichess sending to our browsers.. I thought it was the Fairy version.. anyway will test all.
use the log which is equivalent to command line.....if i can't get the PV line here too.. (as it keeps going for infinity).
so i will stick with this.. closer to an example of what a user might enjoy when using engine as analytical tool, eyes open.

[Dboingue]

Maybe there is a pîece of information missing.. that I take for granted.

• The SF web evaluation guide.
  find URL. find which SF version actual parameter choices are there. NNue off or not (version too).

• hard to make the proof of concept from lichess analysis UI SF version being 14, and the web guide being unknown version, if ever updated.

so I might require some good will for the proof of concept. or do the whole command line thing with corresponding version once known.

in the meantime. i just put the links and get the results from there, with leafs according to UCI info output for depth 17. also did 16.. but best would be to find a depth that jumps the score so people get the obvious screaming point.

put that in the web guide too. all the PV leaves for known engine.. into the web guide unknown version (maybe it got fixed).

• web guide revisit after more than one year. post link here. and any good information.
• use web guide as static evaluation

(might also try the command line on known local version of SF), in spite of past eval mode syntax ambiguities... does the web guide apply the same exact evaluation function as in SF on lichess or my command line.

does it matter for proof of concept. The point is that one can look at the only full position information that is input to the static evaluatoin (e.g. web guide) and gives the root score value.. i don't get what is so cluttery or meaningless about that. wrong universe probably.

[benediktwerner]

At this point, you're just spamming. I think 16 is a good enough limit.

[Dboingue]

could someone delete this whole issue. Having worked hard on it so uselessly given the self-satified convictions.. is a waste of everybodies times and nerves. got the message about some cultures expectations. my bad. too much expections about lichess.
or delusions.. . i find this condescending reception. indigestion follows.

[Dboingue]

The real meaningless PV main sequence is the one that is arbitrarily truncated. none of the position shown there have had the evaluation that the root position get made.. (if any evaluation was made). / We should care about where the meanings come from.. A lot of users are in the fog, and will keep there and keep thinking of engine as ultimate unscrutable source of truth.  Having that last position might unveiled a corner, at the population scale.  Forcing everbody to go commanline to get that basic information seems a bit outdated thinking to me./ Also there would be no additional clutter, as the PVs are already collapsible to one liners. It is up to the user to have it take the full space.. That was point #3 in first post.  I am already not very concise. Having to untangle the past issues on both lichess and SF, to support my point of lichess not having updated its design choices for the news that now SF does provide the full PV depths in output, and that not being the case before, was the conclusion keeping 16 from being updated, is a recipe, for lots of rambling, not very efficient, on my part. Best consider the facts are they are now, perhaps than the historical decision logic being possibly moot. Le 29/08/2022 à 16:52, Dboingue a écrit :

…

long PVs getting inaccurate?  the main PV of 22 or 50 in puzzles creation, being inaccurate? The score attribute to current root search comes exactly from the exact position information all the way down the PV. I am not talking about the PV itself as important, but the last posiiton which evaluation is exaclty and accurately what the variation first move received as score being printed on the UI. This is about understanding the point of view of the engine.   Yes the path will change if updating root. but the best move advertised at single root search is exactly the accurate result of the min-max optmization.  I will wait for more voices. to show why the cap is at 16 having been based on SF not giving it in the past. It may have been linked to the other direction of how many PVs, and is often the source of confusion, in the spaghetti of issues.  I wish I did not have the burden of untangling again. But the fact is that now SF gives it all.   And it did not in the past.  Maybe read about min-max basics. (I can't believe i am the one resorting to such burden of proof transfer, but I hope others have read the first post)...   issue archeleogy, I wanted to avoid.. but maybe i should not even have mentioned their existence.. my bad. i offered a distraction counter-argument. Le 29/08/2022 à 16:34, Benedikt Werner a écrit : > > I don't think the SF issue you're describing (#2423 > <#2423>) has anything to do > with the cap in the UI. One was about showing more, the other is about > showing less. > > pvs are currently capped at 16: > https://github.com/lichess-org/lila/blob/master/ui/ceval/src/view.ts#L388 > > Long pvs eventually get quite inaccurate though and it does clutter > the UI so not sure how much sense increasing or removing the limit makes. > > — > Reply to this email directly, view it on GitHub > <#11452 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ADNEZIFKR6LQ2ANZAOZJD5DV3UNFDANCNFSM576V4RMQ>. > You are receiving this because you authored the thread.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#11452 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADNEZICVYSNGFWT37HRYNLTV3UPKXANCNFSM576V4RMQ>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>