On 12 July 2012 20:59, pharmtech <[email protected]> wrote: > On Jul 11, 8:39 am, Oisín <[email protected]> wrote: > > Is it really more computationally difficult to do? > > Calculating "overdueness" probably isn't difficult. But, I think the > proverbial devils are in the details. For example, most people are > going to take a few days to catch up. Should cards that are normally > due those days take priority over cards that are more overdue (defined > as the overdue as a percentage of interval)? If the goal is to focus > one's attention on cards at the greatest risk of being forgotten > (their distance from the Forgetting Curve), I think it's reasonable to > treat cards coming due within that catch-up period as overdue > themselves, and show them only when their "overdueness" is greater > than any other card. > > That would get complicated. And, do you dynamically address overdue > cards until they are done?
I think you might be making it unnecessarily complicated. Rather than have separate treatment of overdue and "normally" due cards, we'd just have a slightly different scheduling rule. At the moment, let's say the rule is that the next card we review is the one with the lowest interval (plus a little random noise to reduce ordering effects, etc). The alternative rule could be that the next card we review is the one where with the smallest value of (interval/actual_duration). But this would mean that a 5 day card due today would have a ratio of 1, and a 20 day card due today would also have a ratio of 1. This would cause somewhat random scheduling of cards that are all on time (or close). So it might be better to use a weighted ratio like (interval/(actual_duration*0.9)), which would behave the same as shortest-interval-first scheduling in most cases, but take into account very overdue cards with longer intervals. In any case, even floating point division and multiplication in Python isn't very slow. You make an interesting point regarding pre-emptively moving massively overdue cards back to the new card pile. That might be frustrating for users if they felt they would have remembered - it does often happen that I see a 3 month card 3 months late and still easily remember it. Maybe an analysis of that massive stats file will enlighten us on the likelihood of failure when reviewing a very overdue long-interval card :) Or, do you prompt the user with a dialogue > when an overdue condition exists, asking them how many days they would > like to spend catching up? If a goal is specified at the beginning, > overdue cards could be scheduled immediately into that "catch-up > period." Cards coming due (normally) in that period could be > rescheduled in advance (merged into the overdue cards' schedule, > probably near the end of the period). > > I like the idea of asking for a desired end date to be caught up. The > dialogue could show the user how many cards they have to look at > (overdue and regularly scheduled), and the amount of time per day they > have to spend. They could adjust the end date and see how it affects > their per-day commitment. > > The dialogue could also ask them how aggressive they want to be trying > to salvage cards. I.e., how far they are from the Forgetting Curve. > For example: "Your most overdue card has a factor of 6000% (days > overdue as a percentage of interval). At what percent would you like > to push cards onto the New Card queue, not waste valuable catch-up > time on them since they're (in SRS theory) not likely to be > remembered. A good threshold is 400%." > > I think that last point is where such a catch-up system could save a > lot of time and help a user's psychological hurdle. If you could > adjust the cut-off for unsalvageable cards, seeing what it does to > your per-day time commitment, that would help you make a rational > decision about cutting your losses, moving forward, etc. (This along > with an adjustable number-of-days would help a user find a comfortable > *goal* for catching up. That could help psychologically.). > > To me, it sounds good. But, I agree with Peter that it's probably a > lot of work and low priority. It would make a good plug-in if someone > felt the spark of enthusiasm. :) > -- You received this message because you are subscribed to the Google Groups "mnemosyne-proj-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/mnemosyne-proj-users?hl=en.
