-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API improvement: cloud-eval needs several calls to get all the useful information #14278
Comments
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. |
type |
Oh, I forgot the info was there.
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.
The text was updated successfully, but these errors were encountered: