I spoke with A_Blokee about this briefly and he pointed me to this thread. I’ve spent a lot of time analyzing this specific problem of how to calculate the optimal DR for students, and I think I have a lot of solutions for this specific problem.
I’d also like to apologize that I’m really unfamiliar with both rust and typescript, otherwise I would have just fixed the code myself. I have looked a little bit into the code, and found some places to make corrections. My apologies for asking your team to do more work and not doing it myself.
I also apologize that I’m going to make a very long post that’s basically hijacking this thread, but I think this is probably the place to post all of this information and the conclusions of my analysis over the past few weeks.
First, as of right now, the the “Help Me Decide (Experimental)” feature in the latest beta (25.08b4 (d13c117e)) is using an incorrect formula to display the “Time / Memorized Ratio”. It is clear that each data point on that is displaying a value equivalent to (t_end - t_start) / (sum(R)_end). However, this is not the correct formula to use. The correct formula to use should be (sum(R)_end - sum(R)_start) / (t_end - t_start). The reasons are long and complicated and involve multivariate calculus, but that is the correct formula to use. An alternate formula that should also give a similar curve would be (sum(RS)_end - sum(RS)_start) / (t_end - t_start). The reasons for this second equation are way more longer and it’s not even a “correct” formula as much as “probably good enough” and “probably should match” (probably). If anybody would like an explanation as to why these formulae are correct (in the first case) and probably-close-to-correct and a sanity-check against improper simulations in the second case, I can explain it, but this post is already long enough. If both the ΔR/ΔT and Δ(RS)/ΔT graphs give the same (or similar) optimal DR, and it’s in the part of the calibration curve for which FSRS-6 is highly accurate for that user (i.e. >50%), and if the simulation is even remotely accurate in terms of predicting how much time each type of review takes, then that is the optimal DR for that user for that preset which maximizes knowledge per time in app, period. Any a priori assumptions about it needing to be above 70% are not necessarily founded. In actuality, I strongly suspect that a number somewhere between 60% and 75% is optimal for most users.
Because the optimal DR is calculable, and the limits of the optimal DR calculation are known, there’s no reason to even show this graph to the user in the first place. (Although I personally do enjoy it, the average user does not enjoy looking at simulation results as much as I do.) It can just be calculated for the user, and they can just click “Optimize DR”, possibly with a very big scary warning if the value is somehow lower than what would be reasonable for a typical user. Perhaps allow the user to view the graph if they really want to. (I would personally like to!) However, if it is still to exist in the UI, then it would be nice if its domain were expanded from 70%-99% to 1%-99%, so that the user can actually see the optimal value.