Open Siderite opened 8 months ago
Extra note: the computer eval is getting cloud eval information as part of its functionality. It would be efficient if someone might get it from a JS object and not have to do an extra cloud-eval API call for no reason.
The server already gives you the deepest eval that satisfies your multiPv requirement.
For a position, if you request multiPv=1 and the server has 2 evals: [{depth: 30, pvs:1}, {depth: 33:, pvs:2}] it will give you the second one, truncated to just one pv. So you do get depth=33.
Requesting multiPv=1 guarantees you to get the deepest eval available, in a single call. I think that solves the issue, reopen if not.
It would be efficient if someone might get it from a JS object and not have to do an extra cloud-eval API call for no reason
type lichess.analysis.node
in your console
type lichess.analysis.node in your console
Oh, I forgot the info was there.
if you request multiPv=1 and the server has 2 evals: [{depth: 30, pvs:1}, {depth: 33:, pvs:2}] it will give you the second one, truncated to just one pv. So you do get depth=33.
In the case above the depth is higher when you have multiple PVs. I am talking about the other case, much more common, where you have depth 50 PVs 1 and depth 15 PVs 10 and you ask for PVs 10 and you get just depth 15. In my scenario, you could ask for PVs 10 and get two values with different depths for the first move.
I see.
Maybe with a specified parameter that can be cached by the browser, one could ask to get the highest depth for any of the moves. The depth would still have to be linked to the move, rather than to the list of moves in that case.
/api/cloud-eval receives two parameters: fen and multiPv. But most people use small PV if any, so most positions are in the database with 1 pv at large depth and the larger the pv number, the lower the depth.
There is an argument that it makes little sense to compare evaluations at different depths, but at the same time, if you want to know as much as possible about a FEN position, you want the largest depth possible. At this moment, if one needs to get that info, they have to call the API with the same FEN and different PV values.
What I suggest is a parameter for the API to get all the information available for a FEN, with multiPV acting only as a maximum value, not as an exact search parameter. The output, instead of a dictionary of SAN and eval values, would have arrays of eval and depth tuples associated with a SAN.
Another solution would be to accept a list of FEN and multiPV values in the API, which would both help the problem above as well as allowing for a single call for multiple positions.
I admit that I have no idea on how the db structure is optimized, this issue relates to API calls alone.