Set Due Date doesn't update the interval of card

[L.M.Sherlock]

It makes the ivl not align with due, which may induce this problem:

Anki 24.10/11 Release candidate

2024-11-22 minus 2.74 months is 2024-09-01. But the actual last review date is 2023-09-09. That’s the problem. Due to the performance issue, the retrievability displayed in browser column is inferred from due and interval of card instead of the last review date queried from the review logs which is used to calculate the retrievability displayed in card info. [image] I can do nothing here because the due and interval could be changed by other operation that I don’t know.

For example:

I learnt this card today, and the due date is 2024-12-0, the interval is 4 days and R = 100%:

However, if I set due date to 3 days later:

The interval is still 4 days, and the R = 96% which is incorrect:

I must set due date in this way to get correct result:

And 0! also generates wrong result:

Why changing interval is not the default/simple option?

[rossgb]

@L.M.Sherlock

Why changing interval is not the default/simple option?

I haven’t checked but I’m guessing that it could really mess up the SM2 algorithm if it were the default.

Example

Imagine it is a mature card with with:

• An interval of 90 days.
• Is due in 7 days.

You then manually move the due date to tomorrow for some reason.

The next day you see the card and get it correct.

If the interval was left alone it is scheduled >90 days in the future as you would expect (exact amount depending on ease).

If the interval was changed to 1 it would probably be scheduled only a few days in the future and take several answers to recover to an interval of 90+ days.

[L.M.Sherlock]

Fair point. So I think the alternative solution is storing the last review date in the card table of Anki’s database, and then we don’t need to infer the last review date via due-ivl. To infer the last review date from review logs is accurate but too slow for sorting case.

[dae]

@rossgb is correct about the reason. Adding the review date to the cards table would be fairly complicated, as it requires changes to the sync protocol if we make another column (packing into custom data would avoid this), and we’d need measures to deal with older clients that don’t know to write that info.

Spitballing here: would changing the behaviour of set due date when FSRS is enabled be a possible alternative?

[vaibhav]

@dae

packing into custom data would avoid this

I think that packing the last revlog id in the custom data would be the best way out.

Though, I won’t object if you think that creating a new column would be better considering the long-term.

Also see my comment here:

@vaibhav

If someone implements this, we will kill two birds with one stone. We will be able to calculate R accurately when sorting cards during review and we will be able to calculate the exact time elapsed since the last same-day review.

[dae]

@vaibhav

If someone implements this, we will kill two birds with one stone.

Yes, that is appealing. Any extra data we add slows down all card access a bit, but perhaps it is worth it here.