Little off topic, but subjective measurements are becoming more popular in weightlifting circles too. There’s a lot of information encapsulated in our subjective experience.
2 Likes
We reccomend different methods for backlogs.
Also, relative overdueness is different from retrievability order.
I thought I read that for FSRS, it’s basically retrievability order. I’ll check again.
Edit: Here’s the anki guide on it
When using FSRS, overdueness is calculated based on on each card’s retrievability, and the desired retention in the deck preset.
So am I misunderstanding that?
Some of your subdecks can have different DR. One might have .77 as DR and another might have .99 DR. A card with R=0.97 from the second deck will be shown first than a card with R=.77 from the first deck.
1 Like
I’ve read the recommended methods and have used them all. I think just simply using a reverse relative overdueness sort would be better than all those methods.
But that’s just because one would be due in one deck and not the other, isn’t it? Once both cards are due, it’s just an ascending retrievability score sort at that point?
In my example, both cards are due but one card is 2 points below DR and one card is 0 points below DR.
What about a R=0.75 card from the DR=0.77 deck and a R=0.97 from the DR=0.99 deck? Is it proportional, or additive?
Regardless, it’s still just ascending retrievability scores, just in relation to the DR, which doesn’t change my argument.
@Expertium Read the conversation here.
Some of your subdecks can have different DR. One might have .77 as DR and another might have .99 DR. A card with R=0.97 from the second deck will be shown first than a card with R=.77 from the first deck.
In my example, both cards are due but one card is 2 points below DR and one card is 0 points below DR.
It was discussed in [Feature Request] Reschedule cards only if the new interval is different by >x% · Issue #419 · open-spaced-repetition/fsrs4anki-helper · GitHub that a drop from .99 to .98 is a much greater change in odds of recall than a drop from .77 to .75 R. Do you feel it might be worthwhile to calculate the odds here for “Relative overduenes”? Just getting your opinion.
I’ll try to find the code that is used in relative overdueness
EDIT: ok, I think it’s this: anki/rslib/src/storage/sqlite.rs at a437003d1d5b4b6000fce85755e62afe33d12fb6 · ankitects/anki · GitHub
higher the number, the more overdue
(1. / current_retrievability - 1.) / (1. / desired_retrievability - 1.)
So if your DR is 0.77 and the card is at 0.75, the “overdueness score” or whatever is 1.12. If your DR is 0.97 and the current retrievability is 0.95, the score is 1.70.
So the latter would be shown first.
Great, that works exactly how I’d hoped, but didn’t think was the case. I still think reverse relative overdueness is the best way to work your way through a backlog, or any deck really. Probably should just be the default sort for Anki overall.
@dae it’s been a while, and the list has been updated multiple, so here are suggestions that should be easy to implement:
- Desired Retention (and Historical Retention too) should be displayed as a percentage, not as a decimal. It’s more intuitive that way.
- [Feature request] Show a notification after rescheduling cards
- Collapse the field with parameters by default, like this:
This makes it less cluttered and reduces the chances that a new user will think “Oh, I have to understand all of this to use FSRS” or “I gotta tweak these numbers manually”
4. When “Evaluate” shows the metrics, make it like this: “Log loss: 0.5000 → 0.4950, RMSE: 4.5% → 4.3%”. That way users won’t have to write down/memorize the numbers.
5. Make it possible to “delete” the yellow message about Anki versions.
A simple cross in the corner should suffice.
6. Use a more recent date, like 2006 (Anki release year), as the default in “Ignore reviews before”. Also make date in the box faded, just like the default parameters.
Complicates user assistance.
I think we should completely remove it and instead have a keyboard shortcut that copies the FSRS parameters. This allows to hide the field from view (or remove it altogether) and still see your parameters if and when needed.
1 Like
This will not allow manual parameter changes.
Putting proposals into one topic complicates their discussion and consideration. I suggest creating a separate topic for all subsequent FSRS proposals.
Have these features been offered yet? They would look good in a Custom Study.
1 Like
I remember dae not being very sanguine about them.
No, but that isn’t needed either. If you’re testing something like me you can use custom scheduling. A bit of a workaround but works.
The FSRS optimizer is not suitable for all things. Therefore, sometimes you have to adjust the settings manually. I have often seen how people plan their notes in anki for viewing. Since such cards do not imply a remembered/ not remembered answer, the optimizer will not receive useful data either.
Anki allows you to customize a lot of things for the user. It would be very strange if it did not allow you to configure its most important function.