Version 23.10.1 (previous versions too).
When failing a not-new card with missing review history, the review interval almost doesn’t decrease at all, usually just 1/10th to 1/20th of a year.
The intervals also remain unchanged if the user fails the card again 1+ times during the relearning phase.
For example:
Before reviewing:
After rating it “Again”:
After failing it a few more times while in the relearning phase:
It looks like the FSRS parameters may not fully reflect your retention. Have you tried optimizing the parameters using the “Optimize” (Deck Options->Optimize FSRS parameters) button and rebuilding your cards using FSRS4Anki Helper (Reschedule all cards)? Remember to make a backup first (exporting along with scheduling information), just in case.
Relearning cards don’t update the interval until they leave relearning.
Yup I’ve noticed. I was under the impression that built-in FSRS worked in a similar way to SM-2, where rating “Again” a relearning card would decrease its interval but not its ease (and IMHO that’s what would make most sense, but this is a topic for another discussion).
My main point is that failing a card, even just once, should probably reduce its interval more than 1/10th of a year. Especially for cards with such long intervals.
Currently, if you want to see it sooner/decrease its interval, all you can do is to manually “Forget” the card and then reschedule/reintroduce it.
Sorry, I was remembering incorrectly: it’s the due date that’s not updated until the card graduates. And I was focusing on the card info screen, not the answer buttons.
@L.M.Sherlock and @Expertium have been discussing possible changes to improve the post-lapse stability calculations, which tend to over-estimate PLS at the moment. It looks like it would be around 10 months in this case, but because of the low desired retention you’ve set, it ends up being about 2.5x that.
In the current implementation of FSRS, if you press again in the next day, the stability and interval will decrease. But it is unchanged if you pressed again in the same day. Because FSRS only considers the first rating per day for each card.
@dae I just tested a bit more and Desired retention and SM2 retention do not seem to play much role in this.
As a reminder, this problem occurs with not-new cards whose review history is missing (because it was deleted with the console).
Some examples where the pre- and post-lapse intervals/next due dates are almost the same:
Desired retention = 99, SM2 retention = 90
Desired retention = 90, SM2 retention = 90
Desired retention = 70, SM2 retention 80
@L.M.Sherlock I see! As far as my understanding of FSRS goes, it might make more sense if rating “Again” a relearning card, if its not its first review of the day, would decrease its interval without changing its FSRS parameters, similarly to the way SM2/Anki V3 scheduler worked.
@L.M.Sherlock FSRS ignores all revlogs with type=filtered. Should it be doing so when not training?
@jcznk If you test with a regular review, you should see a difference.
Of course, it should.
If a card has a 90 day interval and 89 days have elapsed, ignoring the filtered review would mean reviewing one day early would give a much smaller interval than a regular review, which is not ideal.
IIRC, when the revlog is entirely empty, the first review is used to determine the starting point, so I don’t think you’ll see a change until you review again on a different day.
I (user1823 on GitHub) am not sure how you implemented it. But, I suggested using the interval and ease before the rating for calculating the initial memory states and then updating them based on the rating. If this was implemented as I described, I don’t think that the above-mentioned problem would arise.
For updating the memory states, delta_t will be equal to the number of days elapsed since the last review (which I think the scheduler knows even if the revlog is empty).
Here ‘filtered’ is indicating that the card was reviewed with rescheduling on, but before it was due.
Sorry, I was conflating the memory state derivation stage and the reviewing stage. I gave this another test and it does respond to desired retention changes for me. Locate a card with a truncated revlog history, and look at the answer buttons. Then adjust your desired retention and go back into study, and you should find that the next times have changed.
In this case, the review shouldn’t be ignored. But I don’t know which code ignores it. I remember that the type of this review isn’t filtered in V3 scheduler.
I think you’re remembering the incorrect comment in the source code that was removed. If the user answers a card before it’s due, it’s marked as filtered in the revlog.
Sorry, I forget that. But I remember that we have discussed this issue. And the code adds an extra condition entry.ease_factor == 0 to keep the revlog:
Good point, I’d forgotten about that. 
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
