I’m afraid that’s not the conclusion I reached. I feel like automatic optimisation is something that would be nice to have, but is far from essential. You’ve already stated that FSRS with the default parameters is going to perform better than SM-2 on average. Assuming that’s correct, surely new users would be better off being switched over to FSRS even if they never change their parameters from the defaults / optimise for their collection.
If anything, I feel like this feature is mainly going to benefit/be appreciated by power users who are concerned with maximum efficiency.
The delay would be when the card is answered, not when it’s revealed, and will depend on things like how active the system is. 500ms is a long amount of extra time to wait, and is definitely noticeable even at that point.
Though I suggested it as the first step for developing the automatic optimization feature, I think that it will be helpful for resolving sync conflicts caused due to manual optimization too.
I mean, if the changes in the sync code will be required later when we develop automatic optimization, why not make the changes now so that the conflicts caused by manual optimization are also resolved?
By now, I mean the next 1-2 months (presuming that automatic optimization will take much more time to be implemented).
Plus, making the sync changes early means that we can resolve sync conflicts when automatic optimization is implemented even if the user has a slightly older Anki version on some device.
The changes you proposed are not practical with the current way syncing is implemented. Changing this would be a significant undertaking, and will need to wait for some future revision of the sync protocol.
Dae, with all due respect, your thought process is a mystery to me. Are you seriously saying “Users will not get the full benefit of FSRS, and that’s actually a good thing?”
If you are going to implement something, some feature, then you should make sure that users get as much benefit from it as possible. If you’re not trying to make the user experience as smooth (in the “no unintuitive and complicated actions are needed” sense) as possible and their learning as productive as possible, then what are you trying to do?
I think the only test FSRS (default params) needs to pass if it is to become the default scheduler is “being better than SM2 (default settings)” which I believe it already is. If I assume people do not tweak any of their settings then still for most of the population SM2 shouldn’t be the better working scheduler, If I’m correct.
Now the point being raised here is that you need FSRS to be usable out-of-the-box for which AO is a necessary feature but SM2 (defualt settings) isn’t always usable out-of-the-box either and needs optimisation for itself.
You can surely use SM2 (default settings) as it is but later on, if you want to optimise the settings you will have a much better experience with FSRS. Improving this experience with AO is good idea but I believe AO shouldn’t be a necessary precondition for turning the FSRS toggle on by defualt.
Apart from the five different multipliers, FSRS also gets you rid of two extra settings.
I don’t assume changing default scheduler should have any “blockers” at this point, unless you’re looking at this in isolation. Even without FSRS stats, even without the simulator, even without all the add-on features, removing SM2 as default still gets us a negative opportunity cost. @dae
Now as for AO, I think “periodic reminders” are pretty good alternative and I like the dopamine on hitting the optimize button. I don’t mind putting AO back on the backburner. I think eventually if AO is to be done then what needs to change is the way syncing happens as @vaibhav has said.
I assume you agree with the rest of my writing, specifically when I said AO isn’t a necessary precondition for making FSRS replace SM2. Now as for “periodic reminders” I am not sure if this is doable but I’m thinking of a pop-up that explains optimisation in around two sentences and shows a button that you are asked to click.
edit: also warn people about possible sync conflicts in red.
I don’t agree that making FSRS the default without AO is a good idea, but pop-ups are better than nothing. If I have to choose between pop-ups and AO, I chose AO. If I have to choose between pop-ups and nothing, I chose pop-ups. If FSRS will become the default without AO and without pop-ups…well, if I was a PR guy and my boss told me to somehow convince users that it’s a good idea, I’d ask for a resignation.
IMO, we should also consider the complexity of the implementation. High complexity will induce high cost of maintenance in the long term.
To myself, FSRS-5 is in progress, and I’m refactoring the simulation function. I plan to use a simple alternative method based on expectation to simulate the stability transition during the short term schedule instead of using a sampling-based method. It may result in a slight inaccuracy but it’s simple to implement (still a little complex, but more simpler than the sampling method). I think it is a trade-off.
We all agree that 4 > 3 > 2 > 1, right? @dae I want to ask you too. Ideally, level 4 is how Anki should work. If level 4 is unattainable right now (due to syncing issues), do you think that level 3 is feasible? I would be ok with level 3, but not with level 2. Level 2 feels like too much wasted potential.
And just to clarify, pop-ups shouldn’t depend on whether the user used “Optimize all presets”, like right now.
I think if FSRS were to become the default scheduler, some changes will need to happen around the same time.
I have noticed that the word SM2 isn’t mentioned anywhere except the tooltip for FSRS. In stead of using SM2 equivalent terms like Anki is used instead. I believe we should be following the same precedent.
To make things intuitive & user friendly—
Rename the FSRS category to Scheduling.
Replace the FSRS toggle with a toggle for SM2 instead. This will be placed in Advanced. Information about FSRS will be put in the tooltip for this.
Rename FSRS parameters to parameters.
The yellow box with the message “Please ensure all of your Anki clients are…” will need updating.
Update all relevant tooltips to reflect the changes made. I found these will need updation: tooltips for FSRS parameters, Ignore reviews before, Reschedule cards on change and Historical retention.
[edit: the manual would need to be updated. there should be a seperate section for SM2 specific settings like “easy interval” and “minimum interval” just as there is a seperate section for FSRS now.]
Why wouldn’t enforcing a sync after optimization work though? Make it so that any optimization (all presets or one) has to be followed by syncing. Then the only way for things to go wrong is if one device is connected to the Internet while the other isn’t.
Isn’t that the problem? If the other device isn’t synced with AnkiWeb then the two devices will have different memory states for the same cards, after optimisation. Not a lot of people are consistent with syncing, so I see problems with that. You might do a sync in one device which changes memory states of all cards after a parameter optimisation. Later, you might study from a different device which wasn’t synced before. The study changes the memory states again for some cards. Now on sync, you need to keep the reviews from second device but change the DSR values somehow, in accordance with the new parameters from 1st device.
@Deranged6605 This is the “whole, seperate topic” about auto-optimisation (AO). We did have some tangential conversations here.
I’m talking about a device that isn’t synced + isn’t optimised, and a device that is synced + is optimised. It’s possible to not be in sync with another device while being in sync with ankiweb (emphasis on device versus ankiweb). It’s also then possible to have a situation where a card had its memory states updated in one device, and had a review log from a different device at a later time. AFAIK these changes cannot be merged.
That is a pretty big difference, far from negligible.
The whole point of FSRS is that it adapts to the user. Not optimizing FSRS parameters not only makes it less accurate, but it also means that saying “You don’t need to adapt to this new algorithm, the algorithm adapts to YOU!” would be a lie.
