Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set due date + FSRS + forced interval #3701

Open
dae opened this issue Jan 7, 2025 · 1 comment
Open

Set due date + FSRS + forced interval #3701

dae opened this issue Jan 7, 2025 · 1 comment

Comments

@dae
Copy link
Member

dae commented Jan 7, 2025

With SM2, a user can change the due date of a card, and optionally adjust its interval at the same time. e.g. change it from being due in 10 days to being due in 3, and optionally make subsequent intervals be based on an interval of 3 instead of 10.

With FSRS, the interval is ignored and stability is used instead, which means "3!" and "3" currently do the same thing as far as FSRS is concerned.

Originally reported on https://forums.ankiweb.net/t/set-due-date-hide-set-interval-to-same-value-if-fsrs-is-enabled/53890

@user1823
Copy link
Contributor

user1823 commented Jan 7, 2025

"3!" and "3" currently do the same thing as far as FSRS is concerned.

True, but the reality is slightly more complicated when you also consider the effect on the calculation of R during sorting & searching. Reproducing some explanation from my comment in AnkiDroid repo:

Regarding the value of the checkbox:

FSRS user:

  • No effect on scheduling
  • Affects searching/sorting. But neither true nor false would result in correct behaviour. Correcting the sorting/searching requires either
    • changing value of ivl to the exact number of days between the due date and the last review date (43 days in my example above)
    • storing the value of LRD in the cards table, which dae has already agreed to.

Originally posted by @user1823 in ankidroid/Anki-Android#17707 (comment)

Though storing the value of last review date in the cards table would solve the issue, it will also increase the size of the database, which is already a concern for some people.

So, I tried to implement the other option in #3688, incorrectly believing that it should be trivial to implement. If someone knows how to get that PR to completion, please feel free to do so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants