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

A special case where "Ignore reviews before" won't work.md #671

Merged
merged 4 commits into from
Aug 12, 2024

Conversation

Expertium
Copy link
Collaborator

No description provided.

@Expertium Expertium requested a review from L-M-Sherlock July 20, 2024 16:18
@Expertium Expertium requested a review from user1823 July 20, 2024 16:21
@user1823
Copy link
Collaborator

Would it be too much to ask people to hit "forget" on all their cards to generate more learning steps if changing their review habits?

Ideally, the users should NOT do this because the estimates of initial stability won't be accurate in that case (resetting the card in Anki doesn't delete the memories in the brain).

The ideal solution is that they continue to learn similar new cards. But, I know that this is not possible in every case. I don't know what's the best solution.

Originally posted by @user1823 in ankitects/anki#2922 (comment)

@user1823
Copy link
Collaborator

user1823 commented Jul 21, 2024

Basically, in such cases, the user has to choose between two options:

  1. Not using the ignore reviews before option and optimizing parameters using skewed review history
  2. Using Reset and generating parameters with inaccurate initial stabilities. (Remember that the initial stabilities are among the most important parameters.)

I don't think that we should advise choosing one of these two. The option that is better for one user may not be better for another user.

@Expertium
Copy link
Collaborator Author

Yes, but we do have to advise something that isn't "Keep seeing an error that says 0 reviews found"

@user1823
Copy link
Collaborator

I really don't know what to advise. Suggestions are welcome.

@Expertium
Copy link
Collaborator Author

Expertium commented Jul 21, 2024

I see 3 possibilities. The ones you mentioned + keep using the default parameters. Using the default parameters is probably worse than either of the two options, since the parameters won't be personalized at all. So we could advise users to choose option 1, we could advise users to choose option 2, or we could tell them about both options and let them choose, but that introduces an extra cognitive load, which isn't great. Honestly, I'm not sure myself.
@L-M-Sherlock what do you think?
(option 0: rework this feature so that it actually ignores reviews, not cards)

@user1823
Copy link
Collaborator

By the way, there is a fourth option too. But, it is only for advanced users.

This option involves modifying the review history, as I advised a user here: #614 (comment)

@user1823
Copy link
Collaborator

(option 0: rework this feature so that it actually ignores reviews, not cards)

This is not possible because the optimizer can't work on incomplete revlogs.

@Expertium
Copy link
Collaborator Author

But memory_state_from_sm2 is a thing

@user1823
Copy link
Collaborator

But memory_state_from_sm2 is a thing

See open-spaced-repetition/fsrs-rs#114

@Expertium
Copy link
Collaborator Author

Expertium commented Jul 21, 2024

I think the crux of the problem is that we can't quantify which of the 4 options - default parameters, Reset, optimize on bad review history, optimize while using memory_state_from_sm2 - provides the best (well, least bad) result. If we could rank these options somehow, we could say "Well, they're all bad, but this one is less bad, so let's go with the lesser evil".

@Expertium
Copy link
Collaborator Author

@L-M-Sherlock thoughts?

@L-M-Sherlock
Copy link
Member

It's impossible to ignores reviews, not cards because reviews are also used to construct the training features.

@Expertium
Copy link
Collaborator Author

So what do we recommend to people who reviewed all cards before the selected date and do not plan to add new cards?

@L-M-Sherlock
Copy link
Member

If they misused hard button, I remember that @user1823 provides a solution to modify the database. Maybe I can port it into the helper add-on.

@Expertium
Copy link
Collaborator Author

That's complicated, I wouldn't recommend that to everyone. We need something for an average user.

@L-M-Sherlock
Copy link
Member

If I port it into the helper add-on, it will be very simple. Just click a button. And I think this case is rare. Maybe we cannot treat them as an average user.

@Expertium
Copy link
Collaborator Author

Ok

Copy link
Member

@L-M-Sherlock L-M-Sherlock left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@L-M-Sherlock L-M-Sherlock added this pull request to the merge queue Aug 12, 2024
Merged via the queue into main with commit 0e20b74 Aug 12, 2024
@L-M-Sherlock L-M-Sherlock deleted the Expertium-patch-1 branch August 12, 2024 02:06
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

Successfully merging this pull request may close these issues.

3 participants