This option doesn’t have a specific explanation in the help menu. As a result, it shows the last selected option instead of going to the corresponding explanation context.
Yeah, I reported that here: Anki 25.06 Beta - #10 by Expertium
1 Like
Hmm, in the past I was able to check the output of the Evaluate before/after optimize and based on the logloss/RMSE improvement, I’d decide to keep the new params to keep the old ones. Taking new params sometimes means getting a lot more reviews or having a backlog to do if you reschedule, so to take the decision I was checking the improvement I was getting to know if it was worth it or not.
Any way to assess how better the params are after an optimize now ?
Was is a popular demand ? It feels like it is being forced on FSRS users without much consideration for the majority of users ?
4 Likes
When asked to choose between keeping Evaluate, removing it, and reworking it into a “health check”, most people voted for health check as their number 1 preference. Though, to be fair, the final implementation ended up being quite different from what I sketched in the survey, so I can’t be 100% sure that people will like it.
And you’re not supposed to decide which parameters to keep, the whole point is that FSRS does that for you.
I plan in the future to make it so that there’s only one back-end call when the value is first changed and to have the workloads cached on the java-script side. Problems with the timing should be solved by that.
2 Likes
Here you go. If anyone has any opinions on what they actually want it to say please give them.
I think the explanation could include why this option is slow and the pros and cons of disabling it. That would help users better understand the consequences of disabling or not disabling it and make a more informed decision.
2 Likes
Here you go.
1 Like
When you get 500+ reviews to do as a backlog to earn a 0.01% RMSE, I guess I still want to chose myself if I take the hit or not.
1 Like
An issue with filtered deck has been observed: When filtering for new notes using “is:new”, the count is incorrectly displayed in the “Due” column instead of the “New” column.
Anki 25.06 (c1fc4592) (ao)
Python 3.9.18 Qt 6.6.2 PyQt 6.6.1
Platform: macOS-15.5-arm64-arm-64bit
As far as I know, that’s the normal behavior when you have reschedule-based-on disabled for your Filtered deck. I don’t think that’s new in the beta.
The new “Approximate Workload” popup when you change the desired retention of a preset is pretty cool, but I noticed that its estimations seem inconsistent with the “Compute minimum recommended retention” option in the FSRS simulator. in the simulator, the Minimum recommended retention is exactly 70% for every one of my presets, but according to the popup, the desired retention with the lowest estimated workload varies more. it ranges from 71% to 78% depending on the preset.
is this intended behavior? which one should I trust? to be safe, I went with the one that was closer to the default desired retention of 90%, which is the new popup in all cases, but I was curious about why the results appear to be different between the two.
CMRR doesn’t use “minimum workload” as a basis for calculating the recommended retention.
This is twice now I had to clarify this, maybe we should mention this in-app.
Oh, well yeah I don’t know what it means then. I thought that it gave you the desired retention that would have you studying the least before the studying amount starts to increase again due to an increasing lapse rate. if that’s not it then I don’t know what it’s for or how I should use it.
Does that mean that CMRR and the popup aren’t intended to be for the same use case? I wanted to use one of them to guide the desired retention that I set for each preset, because other than “I want to learn the material” the desired retention of a preset isn’t important to me. I just want the “best” one, so I set it to whichever one Anki says is the best one.
Yes. For your use case just use CMRR.
1 Like
CMRR minimizes the workload/knowledge ratio, where “knowledge” is the sum of probabilities of recall at the end of the simulation. But it has issues with FSRS-6, so we’re looking for alternatives right now.
1 Like
btw what has been considered other than S×R?
Btw @dae, I want to do something unorthodox (well, make Luc do it, lol): temporarily add an option to choose one of three definitions of “knowledge” for CMRR:
- sum(R), aka same as right now
- sum(average R over the next 365 days). This is better because it takes into account how slowly R decays
- sum(S*R). This is better because it takes into account how stable the knowledge is, but is more aggresive than 2, and has some issues. For example, I wouldn’t say that I care about a card with S=50 years ten times more than I care about a card with S=5 years (they’re both in the “very very stable” mental bucket for me), but the math works that way here. For the same reason, I wouldn’t say that I care about a card with S=0.1 days ten times more than about a card with S=0.01 days, they’re both essentially worthless
It would be a dropdown menu under “Compute minimum recommended retention” in the simulator window.
Then we would ask people on the forum to try all three and decide which one gives the most intuitively nice values, aka just go based off vibes. Then the dropdown menu would be removed in the final release.
I’m asking because I don’t think that there has been a precedent for “add a feature only for one beta”, and obviously Luc doesn’t want to make a PR only for you to reject it.
- Why not test it using the Python simulator?
Because it would be nigh impossible extremely annoying to make every single thing exactly identical to Anki. Especially states of already existing cards, that would be actually impossible without a simulator that is hooked to Anki.
And also because we need more beta-testers than just me and Luc.
1 Like
was putting min and max cap for S considered (in S×R)? so that cards with 1d or less than 1d stability would be having the same effect on CMRR. or cards with 5 yrs/10 yrs stability for that matter.