Ordering Request: Reverse Relative Overdueness

So @L.M.Sherlock, because this is getting confusing now :smile::

@Expertium :

Also, Jarrett, another suggestion: learn_span = deck_size / learn_limit_perday . This way the number of days to simulate is automatically adjusted if you change the deck size from 20k ot something else

@vaibhav :

Doing some quick math, the derivative of R comes out to be proportional to R3/S. For the reason mentioned by you, I think that sorting in the descending order of R3/S can be quite effective (when there is a backlog).

With taking into account

  • backlog size
  • days taken to work through backlog

Even though it confirms the opinion of others here that Anki can be daunting for new users?

A product that ignores the views of potential users will limit it’s potential client base. Any company worth its salt that produces a product would note what potential customers say prevents them from using the product.

Not everyone thinks that anki is difficult for beginners. Following the opinion of users does not always benefit the product.

1 Like

Jarrett already implemented the first suggestion. R^3/S is interesting, I’ll see if I can do it myself later (I’m not at home right now)
@vaibhav how did you get R^3/S?

Well, just about any review of Anki that I’ve seen has mentioned it’s complexity as a negative.

We’ll just have to agree to disagree.

I have proposed having two different layouts (Beginner/Advanced) in the past, Dae wasn’t very fond of that idea.

It is (quite) a common belief held by everyone, except for expert users.

Well, just partially differentiate R(t,S) with respect to t and then substitute (1 + 19t/81S) in the differential with 1/R^2.

I think the user experience design should get more task oriented. I agree with them.

I know you have to differentiate the forgetting curve. I guess R(t,S) with respect to t is the forgetting curve, yeah?

Yes, in FSRS, the forgetting curve is given by

$$ R(t,S) = \left(1 + 19/81 \cdot \cfrac{t}{S}\right)^-0.5 $$

See The Algorithm · open-spaced-repetition/fsrs4anki Wiki · GitHub for more details.


@dae, please enable math in the forums if it isn’t already enabled. See Discourse Math - Plugin - Discourse Meta for instructions.

2 Likes

I am too and the only way I can see that even being possible is that the desired retention level is not set at the actual best place.

PRL Descending is getting you as close to the desired retention (DR) level as possible. If you’ve chosen a suboptimal DR, and let’s say for example a lower DR is better, then a sort that is less efficient and is causing you to get average reviews at that more optimal lower retrievability is going to look better.

@L.M.Sherlock I know this would be really easy to code, but might take a long time to run… Can you loop the simulations from DR 0.70 to 0.90 (or whatever range you’re sure is going to capture the optimal number) in increments of 0.01 and show the tables produced for each? I know you guys already settled on 0.90 being the best, but you didn’t do this with all the different sort options. PRL Descending just makes too much sense for it not to have won lol.

Nice, I tried to use latex here just last night and saw it wasn’t working.

Actually, it’s around .86 which CMRR gives you. Now it’s .85 I think. I don’t think it has anything to do with retention though. Look at the tables.

By the way, I want thank you for initiating this discussion here. We wouldn’t have gotten this far without that nudge.

1 Like
  1. What’s CMRR?
  2. The simulation is running it at 0.80, so if that’s not optimal then PRL Desc won’t be optimal.
  3. Desired Retention doesn’t have anything to do with retention? I’m probably misunderstanding you. What tables are you referring to?

For sure! Been on my mind for years lol

1 Like

Compute minimum recommended retention which is basically retention for which workload:knowledge is the lowest. Knowledge is sum of all R.

Now that I look at it, your solution gets us very close to that .8 R. Amazing!

I was thinking the results have nothing to do with retention. I was talking about the tables Sherlock provided.

I am thinking about it but how should that be done? “Days taken to work through backlog” can simply be total due/review limit.

That doesn’t account for cards showing up again and again before you’ve gone through them all, which depends on each individual stability score.

The sim is using DR to determine when cards become due (I assume). This will definitely affect the results.

Review limit counts cards.

The sim is using DR to determine when cards become due (I assume). This will definitely affect the results.

Yes, but I was looking at the data in last column (seconds per learned cards or something). PRL is performing worse than other candidates. But I get your logic now.

That metric is really hard to parse and may not even be useful at all. “Total Remembered” isn’t actually number of cards, it’s total summed up retrievability (which can just be thought of as average retrievability for sake of understanding). Dividing that by time doesn’t really make sense.