[Question] Compatibility with Add-on "Learn now & Grade now" (Documentation)

[Exponent4806]

Research

Enter an [x] character to confirm the points below:

• [ x] I have checked the FAQ and could not find an answer to my question
• [x ] I have read the wiki and still felt confused
• [x ] I have searched for similar existing questions here

Problem Description

The Add-on "Learn Now & Grade Now" seems at least partially compatible with FSRS. However, I am not completely sure, and it is missing in the list of "compatible add-ons" on GitHub.

That add-on has 2 functions:

1. Learn Now
2. Grade Now

The Grade Now function (2) is useful to manually fail a card if one finds a word/concept outside Anki and is unable to remember it. I have been using it for months without any issues apparently.

However, I used recently the function "Learn Now" (1) and it messed up my deck. I had no more cards to review within a week and the FSRS algorithm seemed to be disrupted.

Questions

• Could you please kindly check this compatibility "issue" @L-M-Sherlock ?

• It would be helpful to add the "Learn now & Grade now" in the list of "compatible Add-ons" (either yes, no or partially compatible).

[Exponent4806]

> 8. Please mention that no add-ons that modify cards' intervals or Ease should be used when FSRS is enabled. #486 (comment)

The Add-on "Learn now & Grade Now" only "fails" a card via the browser exactly as if the card would have been seen. Is that correct Tatsumoto ?

The problem seems to lie in the "learn now" function. After using it, the schedule with FSRS went wrong... I had to restore my deck from a Backup because all the schedule was dysfunctional... 😭

[Expertium]

While I don't advise using any add-ons that affect scheduling with FSRS, @L-M-Sherlock, please check compatibility of this add-on.

[tatsumoto-ren]

I used recently the function "Learn Now" (1) and it messed up my deck.

What happened exactly?

"Learn now" doesn't do anything special, it simply changes the card's queue and type (and a few less significant parameters). See here.

But I don't use fsrs and can't say anything about whether the add-on is compatible with fsrs.

[L-M-Sherlock]

"Learn now" doesn't do anything special, it simply changes the card's queue and type (and a few less significant parameters)

FSRS calculates the initial memory state in the first learning when the card is new. If a user changes the card's queue and type, the initialization will be skipped. If the user learns the card, FSRS will calculate the initial memory state via converting the interval and ease of the card. It will mess up the scheduling of cards.

[L-M-Sherlock]

"Grade now" works with FSRS. The only problem is Time=0⁩s.

[Exponent4806]

"Grade now" works with FSRS. The only problem is Time=0⁩s

Should FSRS users avoid completely using the Add-on "Learn now & Grade Now" ?

I have been using the "Grade now" function of the add-on during 8 months together with FSRS.

I have not noticed any damage to my collection because I rarely fail cards in such a way. For example, I only fail 2-3 cards per week with the "Learn now" function of the add-on. However, my collection contains 20.000 cards and I do not notice any difference....

Should the add-on simply be added to the list of "incompatible add-ons" with FSRS? 🤔

[L-M-Sherlock]

If you use "Grade now", please avoid to use Compute optimal retention (experimental), because it relies on the time of each ratings.

[Expertium]

I think it's better to mark this add-on as "incompatible".

[tatsumoto-ren]

Since it's a bug in FSRS, I think this issue needs to stay open until FSRS becomes compatible with the add-on. Alternatively, we could create a new issue and mark it as a [Feature Request].

[L-M-Sherlock]

Since it's a bug in FSRS

I don't think it is a bug in FSRS. Because we couldn't distinguish a card with incomplete revlogs in learning stage and a card which Learn now. @dae, what do you think of?

[tatsumoto-ren]

FSRS calculates the initial memory state in the first learning when the card is new.

This is where the possible bug is located. The reason is that you need to calculate the initial memory state when a card graduates. Before it graduates you can't tell anything about its memory state since the data is insufficient.

Are there any other ways the "learn now" feature could be fixed?

[L-M-Sherlock]

This is where the possible bug is located. The reason is that you need to calculate the initial memory state when a card graduates. Before it graduates you can't tell anything about its memory state since the data is insufficient.

It's intended for FSRS. FSRS just uses the first rating to initialize the memory state. And the subsequent reviews of the same card will not update the memory state.

[dae]

There's already code in Anki to infer memory state when it's missing, so I'd expect things to already work. I suggest you start by describing exactly what you mean by "the schedule with FSRS went wrong", and provide us with a set of steps we can take to reproduce the issue you're seeing.

[L-M-Sherlock]

Normal case:

1. Add a new card
2. Press Good

Current case:

1. Add a new card
2. Learn Now
3. Press Good

The stability are inconsistent.

[dae]

In the second case, there are no review logs, so Anki is calling fsrs-rs's memory_state_from_sm2(ease_factor=2.5, interval=0, sm2_retention=0.9). So perhaps that function needs adjusting if you think its current outputs for that input are inappropriate?

[L-M-Sherlock]

I would like to ask @user1823. My initial solution is don't convert from sm2 when the interval is shorter than 1 day (or the revlog is (re)learning), and initialize the memory state from the rating.

[user1823]

My initial solution is don't convert from sm2 when the interval is shorter than 1 day (or the revlog is (re)learning), and initialize the memory state from the rating.

I think that the only exception to calling memory_state_from_sm2 in the event of absence of revlogs should be the case when ivl = 0.

The problem with also skipping the other cases where ivl < 1d is that we can't know what the previous rating was. Remember that we need to deal with the cases other than the present case (the one resulting from this add-on).

[L-M-Sherlock]

I think that the only exception to calling memory_state_from_sm2 in the event of absence of revlogs should be the case when ivl = 0.

So what's your suggestion for dealing with the current issue?

[user1823]

When ivl = 0, don't call memory_state_from_sm2 and initialize the memory state from the rating.

This suggestion is based on the assumption that if ivl is less than 1 day ( say, 6 hours), it is not considered to be 0.

[L-M-Sherlock]

The stability are inconsistent.

But in this case, the ivl = 10 minutes.

[user1823]

If I have understood it correctly, in this case, Anki will call memory_state_from_sm2 before the rating seen in the card info. At that time, ivl = 0 and that's the main issue here.

[L-M-Sherlock]

Anki will call memory_state_from_sm2 before the rating seen in the card info.

Here is the relevant code: https://github.com/ankitects/anki/blob/046ae539fb4bf266a408986e2cf71c5730759607/rslib/src/scheduler/fsrs/memory_state.rs#L253-L269

I will dive into it later.

[user1823]

I guess that the issue can be fixed by changing line 163 of the above-mentioned file to:

if self.ctype == CardType::New or self.interval == 0 {

[dae]

I've merged the PR in (thanks!), and will leave it up to you two to decide whether 84% is an appropriate difficulty for an ease of 2.5 (it seems rather high IMHO).

[L-M-Sherlock]

will leave it up to you two to decide whether 84% is an appropriate difficulty

In my test, it's 44%.

[user1823]

Dae is talking about the case when interval is less than 1 day, but not zero.

I have proposed a (hacky) solution in #540 (comment). What is your opinion on it?

[dae]

@L-M-Sherlock I'm guessing you're testing with your PR branch and ivl=0, which treats the card as if it's new. What I'm focusing on is non-new cards. For example, a card with interval of 1 day and no revlog is given a difficulty of 75% when you press any of the buttons, despite the ease being 2.5. 10 days gives a difficulty of about 6.2, and 50 days gives a difficulty of about 50%. Should the interval even influence the difficulty assignment from SM2?

[L-M-Sherlock]

And should a card with a non-zero interval and no review history/ease 2.5 be given a difficulty of 84%

For (d=84%, s=0.1, r=0.9) and default parameters, the SInc is e^1.49 * (11 - 8.56) * 0.1^-0.14 * (e^(0.1*0.94) - 1) + 1 = 2.472950593. I think it's OK.

[user1823]

@L-M-Sherlock, I think that you are right.

I (and probably Dae too) was thinking that because the D was high, it can cause the intervals to rise too slowly. But since the stability is also low, the SInc is not that low. In fact, the calculation of D is aimed at ensuring that SInc is roughly equal to the Ease.

Another problem I thought was that this high D can cause issues when the S becomes large eventually. But, the D can be decreased by mean reversion with subsequent reviews. So, this issue should not arise.

Currently, I have one point related to this issue worth pondering over:

Wouldn't it be better to use w[0] as the minimum value of stability in this function rather than the hard-coded value of 0.1?

My reasoning is that the stability of any card should not be lesser than the stability of a failed card.

[L-M-Sherlock]

w[0] is the stability of a card that is forget in the first learning. If the card is forgot again and again in the subsequent reviews (not in the same day), the stability will decrease.

[user1823]

Yes, you are right. I think that we can close this issue now.

@Exponent4806 @tatsumoto-ren, the next version of Anki will be fully compatible with this add-on. Until then, you can use the FSRS4Anki Helper add-on to reschedule the cards that were studied using the Learn now feature. This will correct the stability and difficulty of such cards.

The Helper add-on doesn't require any modification to be able to correct the memory states of these cards. (I have not tested it but I can't think of any reason why it won't work.)

[dae]

Hmm, I think it might be worth having another think about this. Manually-scheduled cards have quite a different difficulty to normally-learnt cards, and the difficulty doesn't drop when they're reviewed again the next day. Could this be handled better?

https://forums.ankiweb.net/t/will-initial-manual-scheduling-interfere-with-fsrs/37976

[user1823]

In this case, I think that Anki is calling memory_state_from_sm2 at the second rating because the Manual ratings are filtered out.

Possible solution:
If the first rating is Set Due Date (Manual rating & factor != 0), initialize memory states at the second rating (using normal formulas).

[dae]

Basing it off the revlog is tricky, but it looks like we can achieve the same result by examining card.reps instead: ankitects/anki@86aafa7

[user1823]

Good idea. Just to confirm, this happens both while training and while inferring. Right?

[dae]

Training uses single_card_revlog_to_items(), which does not look at card state.

[user1823]

I was being too naive when I assumed that this patch also worked when recalculating memory states and when training. The reality is that it doesn't work in these cases.

Here is why this is not good:

• If this doesn't work while recalculating memory states, the card will have incorrect memory states after the user shifts from SM-2 to FSRS or after the user updates their weights.
• If this doesn't work while training, a significant amount of data will not be available for training (if the user has a habit of introducing new cards via Ser Due Date), which can lead to "underfitting".

So, probably, my proposed solution (#540 (comment)) should be implemented.

[dae]

This, and the previous sm2/missing revlog hacks do apply when recalculating memory states - it is only training where they do not apply. My understanding is that @L-M-Sherlock is not particularly keen to add a bunch of extra special cases when training, but if you manage to convince him otherwise, perhaps we can revisit this in the future.

[user1823]

This, and the previous sm2/missing revlog hacks do apply when recalculating memory states

I may be wrong, but I think that Anki doesn't store the reps count at the time of each review. So, if the card has already been reviewed, say, 5 times, then we can't know whether it had reps = 0 just before the second rating or not.

My understanding is that @L-M-Sherlock is not particularly keen to add a bunch of extra special cases when training

@L-M-Sherlock, I understand that we should use too many special cases when training (because of the risk of corruption of the weights). But, in this case, we have an actual new card that is currently being excluded from training just because it was introduced in an abnormal way.

If the user has a habit of introducing new cards via Ser Due Date, a significant amount of data will not be available for training, which can lead to underfitting.

So, do you think that we should implement my proposed solution (#540 (comment)) and include these cards in training?

[L-M-Sherlock]

If the user has a habit of introducing new cards via Set Due Date

If the second revlog's type is learning, I will consider to include them. Otherwise, they are review cards instead of new cards, because we couldn't assume the user didn't learn the cards' contents beforeSet Due Date and didn't set different intervals based on their own grade system.

[dae]

I may be wrong, but I think that Anki doesn't store the reps count at the time of each review. So, if the card has already been reviewed, say, 5 times, then we can't know whether it had reps = 0 just before the second rating or not.

the new/reps=0/interval=0 path is only taken when FSRS doesn't have any usable revlogs for the card that could be used to infer the memory state.

[user1823]

@dae, I think that we are not on the same page.

Consider the card in the linked Forums post (reproduced below). If it is rescheduled now, Anki will use the memory_state_from_sm2 function at the second rating. But, we want Anki to initialise memory states using the normal formulas at this rating.

[user1823]

we couldn't assume the user didn't learn the cards' contents beforeSet Due Date and didn't set different intervals based on their own grade system.

Yes, this is an important thing to consider (but only when training). So, let's not include these reviews in training for now. In the future, we can probably add another setting to control this.

The reason is simple: The users know how they use the Set Due Date option and, if informed appropriately, they can make a better decision to whether to include these reviews in training or not.

I don't like the idea of adding too many preferences because that will confuse the user. But, FSRS settings are supposed to be moved out of the Advanced section in the future. After this happens, we can add the proposed setting to the Advanced section so that only Advanced users notice it.

[L-M-Sherlock]

Yeah. For example, the sm2 retention has already confused some users.

[siraben]

Hi, I'm the author of the post about manual scheduling in the forum. I have numerous examples from my deck with manual scheduling and lots of reviews. If @L-M-Sherlock, @dae, @user1823 or others would like a copy, I would be glad to send it over email, just reply below.

[siraben]

The reason I sometimes use manual scheduling is for new cards that I would like to see over a period of time. You can select a group of cards without tagging and set due date to 1-7 to schedule it evenly over the next 7 days. Since it seems to interfere with FSRS, I've stopped using manual scheduling for now and manually tag and review by tagged cards instead.

[siraben]

Here's another such card with manual setting.

[user1823]

@dae

In #557, @jcznk has demonstrated that even in 23.12 beta 2, the memory states are not correct when such cards are rescheduled (as I mentioned in #540 (comment)).

So, I think that we should implement my idea, which is reproduced below with some modification:

If the first few ratings are Manual, initialize memory states at the first non-Manual rating (using normal formulas).