I think we should figure out a way to support different spacing algorithms first, then see where this can fit in (e.g. how should it work for algorithms that don't have a concept of ease?).
Besides the main Anki spacing algorithm, there is also a modification of it (https://github.com/brownbat/autoEaseFactor) that would be a nice addition to org-fc.
After a bit of discussion with ~xyank, we have come up with a way this could be implemented.
A problem with the brownbat algorithm is that it relies on the review history (review log in Anki) to compute a moving average over a cards ease. I think this average can also be tracked in a column of the :REVIEW_DATA: drawer, without having to access the review history after rating a card.
The same should apply to the Anki algorithm, too.
I've prepared some changes to the awk indexer to allow it to parse :REVIEW_DATA: drawers with arbitrary columns.
A remaining question is how to determine which algorithm to use for reviewing a card. Currently there is a defcustom
org-fc-algorithmfor this that applies to all cards in the system. I think the only viable solution is to add a
FC_ALGOproperty to each card, similar to the
A defcustom or a file keyword can be used to determine the algorithm to use for a new card.
To find due cards, org-fc only needs two columns of the review data, the due date and the position. Spacing algorithms could then define additional columns and functions to update the review data after a review.
I think for now we can assume that all algorithms work on (a subset of) ratings "again, hard, good, easy".
In preparation for this change, at least three breaking changes are needed:
- The dashboard can't show box/interval statistics anymore because algorithms are not required to define those values
- SM2 specific columns need to be removed from the review history file
FC_ALGOproperty has to be added to each card
Change 1 only affects the user interface and the conversions required for 2 and 3 can be done automatically.
I'm not sure what the best way of applying these would be, either checking for the
FC_ALGOfield at each review and offering to automatically convert all cards or requiring users to call a
org-fc-migratefunction once when updating to new version of org-fc.
My knowledge of probability theory is not good enough to make sense of the math behind it but it might be a good addition to org-fc. Because it handles early and late reviews in a mathematically sound way, the review history can be used to train its parameters when converting a card from org-fc-sm2 to this algorithm.
With a recent commit, the awk indexer can now parse arbitrary :REVIEW_DATA: tables, what's missing is a way to change the algorithm to use for a card (or a collection of cards, by inheriting some "FC_ALGO" property).
Porting the code to EmacsLisp should be easier than porting the Anki algorithm even if the math behind it is more complicated because the code is structured better and there is a test.json file to check if the output values are correct. In the meantime, it should be possible to shell out to python and use the default implementation to compute new intervals & review parameters.