#30
"Perhaps the lichess UI was adapted to some older less complete output version of SF. anyway. I would get justification for this thread as feature request. The patch to dump engine PV display to user variations is half way to the full PV, it is a great step already. Now, the few missing plies to figure out there disappearance."
I'd say what you (and I) are requesting is an option to turn on full display of the variations returned by SF. Lichess is definitely cutting that off. It is easy to prove this by giving the same position to SF running SF in a command window with the same depth that Lichess says was done, and then counting the ply SF returns and seeing that it is cut off in the Lichess display.
We could also go read the Lichess source code. :-)
The motivation for this is that people looking at the output as it is today may think that the evaluation score displayed is an evaluation for the last position in the variation displayed - and that is incorrect.
I know the following should be obvious, but I'll mention it any way (dboing: I know you know this; so not for you)
If one clicks on the last move of a variation, and so is now displaying the last position of that variation, and continues having the engine evaluate, then the evaluation score is probably not going to be the same as the value seen at the beginning. The engine is now searching again and can change the evaluation score because of that. The only way I know to verify the original evaluation score of the last move in a variation is to use the undocumented non-uci command 'eval' by running SF in a command window. Obviously that requires that one understands *how* to run SF in a command window, the uci commands to get things set up to be in tune with the Lichess parameters to SF, and how to interpret the output of the 'eval' non-uci command.
we had to figure out. typo was "we have to figure out" the cases where the Hash table does indeed explain the short PV display, and when it does not.
Currently we are having such cases where alone it does not make sense as cause of shorter than search depth PV display.
The worst problem would be that even the Hash table transposition induced shorter PVs would themselves also be truncated by the wrapper or lichess UI. There is some indication of that, as re-toggling engine on previously searched root and displaying also up to 5 engine variations (PVs), shows all 5 at same shorter ply depth. which is also odd for the same reason that 16 instead of 22 for 5 variations is odd.
The coincidence that all those 5 searches had a transposition at exactly the same search depth.
search depth. good short-hand perhaps. i like horizon, but I would need to always accompany with warning: "in general speak imagery"; because those AB engine searches have evolved from fixed depth searches. But still, there is an horizon (some average search depth). end of terminology tripping over oneself.
#31. well said. thanks for your expression abilities and your research. I should say that you have been my source for the command line experiments mentions in previous posts, and our inbox discussions (also using studies).
It's easy to understand why the site throttles trivial data reporting ... consider the following ...
If it's only yourself who wants it, then it's low impact, but if 100,000 users want it, then more servers are required... or more bandwidth, or more fatter cables or something ...
#33. yes that is one possibility. Or it could have been at one time in the past, and never revisited even if context changed.
i could apply same argument for any of the extra information displayed. why only shave from expected 22 to 16? and why offer 5 shorter lines, and not 4 full ones guaranteed. It does not seem to be applying. you would agree.
But I do wonder about that kind of scaling argument. It is possible, but it can't be used without more specifics.
Any feature request could be dismissed with a canned response using that.
There is the other generic argument that could argue small user case, and man power effort not warranted.
The 2 argument can't be used at the same time though.
If a manpower question. or research still needed to find out where this might happen, then that would be more informative and could at least be worked on if really interested.
A load scale argument does not fit, or if saturation really happens there, I would gladly trade full variation display for less number of variations displayed. That could keep the same load.
It might be a legacy, with little user case or little perceived user case. That would be then need to be confirmed. So we can either move one, and judge if fixable. going to the appropriate code lines, at last,.
Plausible does not satisfy me though. As I have witnessed lichess persistent effort toward an educational and pedagogical rich subset of its platform. studies. the learning section. the puzzle system. These are telling me, that it is important to get some answer or raise the concern.
Given the moot post quote i made from a pull request discussion above, and the recent command line results by jomega with SF14, the assumption of legacy short PVs is reasonable. SF did not do it for a while, and now it does. when did SF fix it. that could be a clue. but would not help in lichess code localisation.
It could be an oversight. In which case, this feedback thread keep making sense. I think. what else could explain it. UI module tab space occupancy. CSS container geometry, or the collapsible feature, or the hover-mini boards...?
It seems like a futile economy. I doubt it is by design.
#31 I believe this is the place in the Lichess source code that is doing the PV truncation.
github.com/ornicar/lila/blob/master/modules/evalCache/src/main/EvalCacheEntry.scala#L46That specific line is defining the MAX_PV_SIZE to 10; which is what I'm seeing in the Lichess GUI. i.e. never more than 10 ply displayed.
The truncation occurs in the code a few lines down from that.
I have no way to judge the economy of the proposal. I originally thought, naively, that this would only affect Lichess space needs based on how many users would opt for this option in their profile (to turn on displaying all of the PV). Now I believe there is a caching system that would be affected.
Now that I've found the code in github, I see that on Feb 3, 2017, the value was changed from 8 to 10. So changing this has been done before, and maybe there is some record of how such a change affects space needs.
#35 I did have some 16 plies in my study experiment. i will tie back here and there.
I will also hunt the issues. I have been there before too.
#36 One place in the code uses 10, and another place uses 16. The place in the code I mentioned in #35 uses 10.
In views.ts, we have
const MAX_NUM_MOVES = 16;
children.push(...renderPvMoves(pos.clone(), pv.moves.slice(0, MAX_NUM_MOVES)));
So that is cutting off at 16.
In Edge, with NNUE on, so Stockfish 13+ NNUE, I get a cut-off at 10. However, if I then push the + to get cloud, after a while it displays 16-ply. Yet, at the moment it is 30/99, and it is still not done. I doubt it will now display more than 16 half-moves. So the eval that is shown is not directly related to the last position after 16 ply. And, as we now have seen from my command line experiments, even if you run SF on the command line so that you can get all these moves displayed and hence get the tip position and give the tip to SF on the command line, the static eval from the 'eval' non-uci command may not match the eval in the gui. The reason for that not matching is because the evaluation SF does that generates the value in the gui, contains a call to qsearch(), which is not done by the 'eval' non-uci command, and qsearch() may modify the "static" evaluation value.
Regardless, I'd like an option to see in the Lichess GUI the entire variation returned by SF in its 'info' output it returns without cut-off.
#35 I should have said this before...
- The requested option need not take more space on Lichess because the long variation does not have to be cached!
It does not take up more time on the servers either because the variation is already there; it is just being cut-off before displaying it.
- Supposedly the point of clicking the + button to get a "cloud" analysis is to see if the eval changes and/or the moves change. Now suppose that the eval does change on doing that, but that the first 16 half-moves are exactly the same as before the cloud analysis. That leaves the user with no way to see the moves that caused the change!
Single stepping the half-moves to figure things out may not work, because then SF starts searching again from those new points and could get a different result.
#39. well adjusted. There is some degree of mystery floating around....
