ReMemorize reschedules counted as a failure
aleksejrs opened this issue ยท 7 comments
When dealing with a huge backlog, I had something like "reschedule_siblings_on_again
" enabled in ReMemorize. That rescheduled lots of cards to shorter intervals, recording the reschedules as failures. The next review was usually also a failure. A couple of months after turning that off, it seems to still be affecting autoEaseFactor. Maybe it should ignore any ratings including and before the last rescheduling to a shorter interval?
That's fascinating, I'm really curious how ReMemorize is rescheduling cards... why would they adding failed reps to the log instead of just rescheduling directly.
Even so, AEF should self-heal, so even if you randomly injected failures in half your cards, the deck will find its way back on track. Once you start getting them right they'll rapidly approach your max ease again once you know them. It will take a few reps for this to sink in, so if your cards are already weeks apart, it won't be immediate. It will always be "part" of the history of the card. But the cards that are being repeatedly reviewed will get fixed the most quickly. They'll never be exactly synched with the cards that were never touched in the first place, but you're going to see them less and less as soon as you get those cards down.
If you find a good example that still seems puzzling, see if you can screenshot just the tooltip that pops up (win+shift+s on windows) so I can see the card history and I'll check it out.
Maybe it should ignore any ratings including and before the last rescheduling to a shorter interval?
An interesting idea, kind of like the request to ignore non-review steps but more general. Wouldn't be trivial, so can't say I can tackle this right away, but I'll definitely give it some thought as an option. Thanks!
Rescheduled cards are logged as ease 0, type 4 (resched). This is also the way Anki 2.1.38+ will log rescheduled cards going forward. I am not familiar with the addon, but I suggest filtering and discarding these types similar to how retention is calculated. Rescheduled cards are not factored into retention calculations.
Rescheduled cards are logged as ease 0, type 4 (resched).
Great to know! That makes sense as an implementation.
Note to self: it's not listed in constants as a card or queue type here, but it is included in the revlog type constants below that. (It's used as the last value in a self.col.db.execute command in the schedulers.)
I will definitely add a check for legal revlog types, thanks for the info.
I think around line 45 in autoEaseFactor.py replacements with these should work, won't be able to test until later this weekend though:
def get_all_reps(card=mw.reviewer.card):
return mw.col.db.list("select ease from revlog where cid = ?"
" and type IN (0, 1, 2, 3)", card.id)
def get_reviews_only(card=mw.reviewer.card):
return mw.col.db.list(("select ease from revlog where type = 1"
" and cid = ?"), card.id)
def get_ease_factors(card=mw.reviewer.card):
return mw.col.db.list("select factor from revlog where cid = ?"
" and factor > 0 and type IN (0, 1, 2, 3)",
card.id)
EDIT: was missing a paren in one of these, fixed it here but be careful, code in comments is poorly tested if at all.
Revlog type 3 would include cramming studies for the V1 scheduler's filtered decks. You probably don't want to include that either.
Not sure if you want to include the ease for learning cards, which is always the same. I suppose you don't? Then type = 1
is that you want instead. Give it some time, think this over.
Oh, can't believe I forgot this.
If you set
"reviews_only": false,
in settings, it will only look at type=1
history.
Maybe the workaround you were looking for all along.
Other thoughts:
-
Anki's constants for card types are off by one from its revlog types and that makes me nervous.
-
Technically, although learning scheduling is fixed, learning ease can be dynamic:
-
Learning / cramming as performance data
For cramming and learning, I see two different reasonable philosophies. First side -- those aren't "real" reviews, so you don't want them to mar your performance record. Second side -- the algorithm is mostly starved for information about performance, so even flawed data is better than nothing. (e.g., if it takes you 10 reps to learn or cram a card, assuming you can't rewrite or suspend the card, it should probably drill you on that a bit more out the gate than one you got in one go.)
I'm a little partial to the second approach, but I think the first one is way more popular and I'm a bit of an outlier.
That's why I originally added the "reviews only" option in settings. Popular demand. Let people pick which philosophy appeals more to them. It literally has a line for type = 1
in the code, so probably already what you were looking for.
I'll still roll a patch for other users too soon. (Even though I have a higher tolerance for lower quality data, rescheduling is just pure noise, I'm not that crazy. :) )
I actually don't use these addons, just giving you some ideas to fixing this as it's related to my addon. And people abusing rescheduling is not something I can control, these projects takes on a life of it's own separate from it's original goals.
I think any review greater than one day (or more accurately, one sleep cycle) should be considered a "real review" and should be factored into the calculations. When I looked at eshapard's original fork couple of years ago, I didn't like the idea of modifying the ease. It'll improve things for one type of cards, but cause problems for other types. That as well as Anki not logging all the info for IM, overdue, hard factor used, removing float points, and the learning steps dependent on the cut off time made the revlogs unreliable.
Probably keeping a separate log would improve the accuracy of thing, but that'll tie the user to the desktop app. Anki's backend codes are a sloppy mess, but at least you seem to be having fun. :-)