octopoulos
commented
3 years ago Idea is pretty good but it's associated to some issues, so, it's not going to be done any time soon, for example: 1) how to display this information, like [8 / 16]? => here, 8 first plies are exactly the same, then they're different and converge again, so the FEN is actually the same after 16 plies (well at least the FEN without the R50 component).
2) agree length should change from a checkbox [ON, OFF] to something like [OFF, ON=both, diverge, converge] I guess?
3) how to display this on the graph, should there be 4 curves, if yes then with which colors, the same colors? or slightly different?
4) CPU issue, this feature will tax the CPU more than the diverging one because this would need to compare FENs, right, backwards? not just moves forwards, and because the FENs are not available in the PVs, they must be calculated. However, this must only be done when a new PV is received, which is rare, so in practice it's not going to slow anything down, except when loading the page for the first time, the site is pre-calculating all those values, so it can display the graph and then of course it stores the value in memory so it doesn't need to be calculated again. There could be a 1 second lag or something depending on the number of moves when loading that game, and depending on the depth of those PVs. Actually, it's possible to estimate that lag, I know the JS code can generate around 30,000 FENs per second from PV lists on my computer, and the WASM library even more (but that WASM library is not directly loaded when loading the page). So if there are 100 moves (200 plies) with 100 plies in each PV, we're at 20,000, so, it would take under a second ... might or might not be acceptable.
(Actually, let me run that benchmark again, the 30k values might be incorrect, I remember that it's 30k times FASTER than the Python code, but that one is certainly > 1 FEN per second, lol!)
Keep in mind that other things are happening when loading the page, this is not the only thing that would add lag, and I'd like to reduce that lag as much as possible. It might be a good idea to generate the values iteratively, so the graph would take a few seconds to generate itself, which is completely fine, but at least the page would load faster.
vondele
mooskagh
currently the gui shows the first diverging ply of the pv, also for the agree graph (which is a very nice graph... always impressive to see two very different engines agree for 20+ plies). However, transpositions are ignored.
So, could we have a counter not only for the first different position in the PV, but for the last same position ? This would take care of transpositions (caveat the 50 moves counter could be different).