Here, as you can see R desc and R asc both have terrible knowledge acquisition rate.
Huh? I don’t see it at all. They all perform very similarly
Here, as you can see R desc and R asc both have terrible knowledge acquisition rate.
Huh? I don’t see it at all. They all perform very similarly
Okay, I should’ve said “worse”. They’re certainly “worse”.
By a very small amount. It doesn’t matter. The difference is big only when there is a big backlog.
Okay, whatever. I’d like to optimise that tiny bit too but that’s maybe just noise.
Man, someone should try out a simulation where you clear backlog seperately and do your prop:due=0
cards regularly.
@rich70521 Hey, as you know rust can you try your hand at this: Add 'reverse relative overdueness'; consider making it the default · Issue #3460 · ankitects/anki · GitHub
It’ll get us the feature quick and none of us need to wait another year. AFAIK this should be fairly easy.
Since the new algorithm is supposed to very effective and I have a huge backlog, I will try out the minimal overdue filtered deck.
Alright, I ran a simulation with an uncapped (99999) review limit instead of just a “large enough” limit of 200.
Hope this helps to clear any confusion about the (un)importance of sort orders when there is no backlog. There may be benefits to interleaving, but this simulation cannot capture that.
You can’t right now, there is no “reverse relative overdueness” sort order (yet).
How do the cards behave in a filtered deck if the parameter by which they are selected changes? Is their order changing?
I see benefit in a more dynamic sort order. If prop:due<0 is:review
cards are zero then we randomise the sort order. If you see here, random is also outperforming others but my main point is interleaving.
By the way, I’m curious about the filtered deck one. Can we not see what sort order works best when you’re clearing a backlog seperately and doing prop:due=0
cards everyday? As I said, that’s the method of clearing backlog manual recommends.
By <1.5%. There is no way this isn’t just noise. Even if it’s somehow not just noise, it’s not a big difference.
If you don’t have a backlog, most of the sort orders are going to seem random to the user though, with a couple exceptions.
Retrievability Descending: All the cards are going to have around the same R, whatever you have your DR set to. The ordering of the minuscule differences in the R calculation are going to be completely random.
Difficulty Ascending: This might be one of those exceptions. There will usually be noticeable differences in the cards D score, even with no backlog. You’ll get easy cards first, hard cards later. If you wanted that with a backlog, I don’t see why you wouldn’t want it without a backlog.
PRL: Basically random. Probably going to be very similar to Stability Ascending when there’s no backlog, but I don’t think that would cause any noticeable pattern to the user.
A bunch of the low-efficiency sorts will definitely not be random with no backlog, like Order Added, but the niche situations people are using those in are times that they don’t want random anyway. The main sorts that are good to use for both backlog and no backlog are essentially giving random when there’s no backlog.
Never used rust in my life
I bet I could figure it out, but I’ve also not really used github much and need to learn how to contribute on there. Been on my to-do list for a while now.
I’m running one right now where the New + Review cards in a day don’t exceed your review limit, which I think is the default setting in Anki. If your review limit is 80 and you have 75 reviews today, you only study 5 new cards.
If you can figure out a way to set that simulation up without the backlog just magically already being there from day 1, sure, I’ll do it.
As Jarrett said, cards need stability, interval lengths, due dates, etc.
I suppose I could do this: learn_limit_perday
would be 20 for the first 1000 days, and 0 for the other 1000 days. review_limit_perday
would be 150. This would simulate getting a backlog in the first half, and then stopping learning new cards to get through the backlog in the second half of the simulation.
I don’t know. I thought you can create a backlog in simulation then take that and run another simulation on it sorta thing.
There’s 20k cards, so if learn limit is 20 for 1k days, you’re getting through all the new cards anyway. Changing the learn limit won’t affect anything after that. Am I missing something?
My bad, my math isn’t mathing.
You can, but that would be a more complicated and time consuming change than the little things I’ve been doing. I’m not really trying to re-code large portions of the sim code, at least not any time soon.
I guess let’s wait for this.