FSRS with known new cards

I recently switched to the FSRS algorithm, and in general, I’m quite happy with its behavior. However, it has broken one use case that I think it might be possible to accommodate.

For several languages I know to some extent, I used the following strategy with shared decks. Since I expected that I would already know a significant fraction of the words, I didn’t want to have them all pass through the new queue and start with short intervals, so I would just set the intervals of the whole deck for some wide range (50-1000 days, e.g.) and know that I would encounter them all in time. If I knew a word, its interval would be suitably long and I wouldn’t have spend much time on it. If I didn’t know a word, its interval would shorten, and I would learn it.

With the FSRS algorithm, since the cards whose intervals were set manually have no review history, my impression is that this strategy no longer works, and that they are treated the same as new words introduced through the new queue. For example, a card with a manually set interval of 1.89 years that I recently encountered for the first time and answered correctly (Good) was assigned an interval of 5 days.

Would it be possible to respect manually set intervals in the new algorithm?

It does respect them. You need to share the screenshot of the card info of one such card to allow us to find out why the manual interval was not respected in your case.

Do not use this for new cards.

Here is a screenshot of the info page for the particular card I mentioned; I can supply many more.

FSRS does not use the length of the interval to calculate the new one.
A technical explanation of the FSRS algorithm

I know. But, there is a function to calculate intervals of cards with incomplete revlogs.

You need to provide a screenshot from the Desktop app (or take screenshots keeping the phone in landscape mode).

In addition, I also require the screenshot of

  • the card info of any similar card that has not been answered yet.
  • your FSRS settings in Deck Options.

If you have any suggestions for handling shared decks with a mix of known and actually new cards with the FSRS algorithm, I’d be happy to hear them. Otherwise, this isn’t very helpful, since with the FSRS algorithm, it doesn’t matter if I do or don’t do it :slight_smile: .

Here’s that card in landscape, another similar unreviewed card, and the FSRS options for their deck:

If you do this, your cards will have low retrievability the next time you view them.
And you will get a longer interval.


Although this is not as big an increase as you would like.

Quoting dae from Incorrect stability of card with incomplete revlog · Issue #2921 · ankitects/anki · GitHub

[In cases of incomplete revlogs,] the review log is only used when the are 2+ usable entries. For 0 or 1 entries, stability is inferred from the card state.

Because there is 0 usable entry in the second card and 1 usable entry in the first card, stability should be inferred from the card state.

Assuming that your Historical retention setting in Deck Options → Advanced is 0.90, the second card should get a stability of 1.98 years just before you press any answer button.

Assuming that state of the first card before the review was similar to that of the second card (apart from 1.89 vs 1.98 years), the interval of the first card after pressing Good should have been much higher.

@L.M.Sherlock, this seems like a bug. Please have a look.

1 Like

This is the best solution that they’ve been able to find for FSRS, because there’s no way to know if the interval created by Set Due Date is “real” or not. [It was touched on briefly here, but the longer conversation is on Discord, and a few different places in GitHub.]

When you’re using it to scatter a set of cards across the next few years, you’re not using any criteria to determine the interval. So you don’t necessarily know the card set for 500d better than the card set for 100d. FSRS can’t rely on that interval at all for setting the memory state.

1 Like

I agree. But, I am not sure how the code is differentiating between the case where the revlog is actually missing and the case where the user has used “Set Due Date”. The card states seem to be similar to me in both the cases and the manual revlog entries are filtered out in the early stages of processing.

Can you link to a PR/commit related to this? Otherwise, I will wait for LM-Sherlock.

I was only party to the chatter, not the coding :sweat_smile: – but I understood Jarrett’s conclusion to be that they can’t differentiate, so those cards have to be treated as New. It’s not an “incomplete revlog, infer from memory state” situation, it’s a “no revlog, no memory state” situation.

I’m looking at the same discussions you (user1823, right?) have been a part of on GitHub.


To save everyone a trip to Discord –

Screenshots of some of the discussion in May (JarrettYe = L.M.Sherlock) --

image

image

In addition to the issue above, Jarrett linked this code –

and this commit –

Thanks for the context. The commit is fairly unequivocal, but I have to disagree with Jarrett/Sherlock’s arguments from a UX standpoint, as it leads to an inconsistency. It doesn’t make much sense to offer the option to manually set the due date if you intend to ignore that value. If the user is allowed to make a deliberate choice to treat some new cards differently from other new cards, then that choice should be respected. Conversely, if you really believe that that’s something the user shouldn’t do for new cards, or that you can’t handle, then you shouldn’t allow them to do it.

1 Like

I think the issue isn’t ignoring the due date that someone set, it’s figuring out the utility of the interval that happened to come along with it, since there is no way to tell whether the interval arbitrary or deliberate. What is the utility in using a completely random number of days for initial Stability – whether that’s what the user intended or not? That feeds garbage data into FSRS – both for this card and for the rest, because of optimization.

Even though we’re discussing this under the umbrella of FSRS, the pre-existing Anki behavior is at the root of it. This is how Set Due Date behaved before as well – Browsing - Anki Manual . The difference is that there was a way around it with SM-2, because the algorithm was going to rely the current interval, and you could feed it what you wanted. [Set Due Date to set the interval for all cards, then Set Due Date to scatter all of the cards to different dates.] It was also a much less sensitive system, so there was no chance of damage.

Using FSRS (and based on your parameters), when you study these no-longer-New cards for the first time, they will have initial S values of (+/- fuzz) 4d for Hard, 5d for Good, and 17d for Easy. That seems like a fine set of options for you to start your cards out. It looks like Good will also set an initial D of 34% – so that card is going to take off like a rocket already. Plug your parameters into the Anki FSRS Visualizer and see for yourself.

@Expertium You said you will run some benchmarks on the 20K collections. What went with those?

@Standfast I agree with you. I bought this up a few months before. I previously lost my scheduling data for some of my cards. For those cards, I set >1month interval but when I reviewed them they got assigned intervals of 4d/5d. I think if I had simply graduated those cards and kept them buried for a month I would have got larger intervals upon review.

Remind me, what was that about?

@Expertium

Ah. No, I don’t think we ended up testing anything. @L.M.Sherlock if I remember correctly, you didn’t benchmark any changes to that, right?