The probabilities are simply internal representation. In the real world, if you know 90 percent of a book, you know 90 percent of it. There is no “But my SRS app is giving me a nice looking graph so my 90 percent is better than others’ 90 percent”.
The mean is actually pretty useless (or much less useful) in statistics if the distribution isn’t Gaussian, and we’re comparing different distributions to each other in this case, which makes even less sense. It’s not just a number that can be a blanket representation of the whole distribution.
You don’t know that at all with the mean. You’re missing so much context. If I have 3 cards with 0.9 R and 3 cards with 0.1 R, that deck will have the exact same total_remembered as a deck with all 6 cards at 0.5 R.
And again, if all my cards are above my desired retention, do I care at all what the R distribution is, or what the total_remembered is? Why would I care? None of my cards are due. If I set the DR higher, I can raise the total_remembered? Should I do that, since I care so much about that metric?
Edit: btw, don’t mean this to sound combative (this isn’t that important lol). I just think total_remembered makes so much intuitive sense, I gotta go hard on the ‘devil’s advocate’ tone to get my point across.
Currently, the only thing you can say is optimal in FSRS is the CMRR value you get which uses total_remembered/total_time. I will raise my DR if CMRR says it’s low.
edit: no, your tone is fine, dw!
edit: See, everyone, I just need data on what should be done. Eternally arguing won’t help. If anyone brings in good data to show something, go ahead but rn I think PSG is working pretty good.
Where can I find the CMRR equation?
1 Like
PSG_desc prefers cards with a smaller R and S. This is not a good thing.
I intuitively understand the why and I gave you the explanation. I agree we need further investigation but I’m not sure it has to be done before there’s a consensus on what should be default now.
For perspective, I’m asking this because dae is unwilling to read the thread so he wants to know what is the consensus.
The sort order probably won’t be implemented very soon so there’s some time to play around with equations and get some more insights. But someone needs to step inside to do that.
This discussion has taken a looooooong turn. I thought it was already decided that Reverse Relative Overdueness is the best order for a backlog, and that we need to decrease the number of sort orders, beginning with the least efficient ones.
Let’s put a cap in the main topic here then. I think I have the option to highlight the official solution since I’m the one who started the thread.
After running the simulations, there were clear winners and losers. Classic Relative Overdueness, retrievability_asc, was an obvious loser, so we need to stop recommending that to people on the guide. Reverse Relative Overdueness, retrievability_desc, is much better. Is it the best? Not settled. I don’t think there’s an obvious best. I think difficulty_asc; retrievability_desc; PRL_desc; and PSG all seem to be about as good as each other.
retrievability_desc does seem to hover above the rest on the graph consistently for the most part, but really anything in that upper tier is probably fine (btw, why hasn’t anyone mentioned difficulty_desc?, it seems to look better than difficulty_asc, just noticed that).
But, PRL and PSG don’t exist at all yet, and are going to be a pain in the ass to explain to the average user. They don’t perform that much better than these other ones, so are they worth bothering to create? Probably not. retrievability_desc wouldn’t be creating a brand new sort, it would be simply allowing the reverse of a sort that already exists.
I think this is the ultimate solution:
Considering Anki allows so much user control to modify cards and make things custom, this would be very much on brand. I don’t see why we wouldn’t implement this. This would shut me up forever, I know that much.
Marking this as the solution unless anyone demurs.
38 minutes ago Expertum offered a cropped version.
The problem with the cropped version is that some sorts lose their meaning if it is not possible to add a second one to them.
Due date,
Deck,
1 Like
A 2-sort system, where one sort covers for the deficiencies of other sort types. That sounds like a cool idea.
-
But then the question arises: Which combination is the most efficient, and how do we know whether a single sort is better than a combination of sorts
-
Then there is the influence of the order of sorts: which sort comes in the first sort slot, which in the second, what if they are reversed, would it still be as effective
-
Also, why only 2 sorts? Why wouldn’t it be 3 or 4 or 5…etc.
That’s a discussion for what to make default, or what to make available to new users, which is an ongoing discussion, and one I’ll definitely participate in. But as far as which to choose in the custom options, just leave that up to the “power users” that want to mess with it. They shouldn’t be messing with it if they don’t have a good reason.
People want at least two for sure. Many people have voiced that want. My bet is if this gets implemented, almost nobody is going to ask for a 3rd sort. It’s just not going to be relevant very often. Two sorts breaks things down to pretty small chunks already.
just leave that up to the “power users” that want to mess with it.
I suppose that makes way for more than just 2 sorts. We could add-in as many as we want (like in Excel). I welcome the idea, but @Expertium probably wont be enthusiastic about this.
My bet is if this gets implemented, almost nobody will ask for a 3rd sort.
Yeah but theoretically you would want a third sort for the same reason you would want 2, and I am reaaaaally power-hungry user. 
1 Like
MMW, it’s gonna be difficulty_asc first, retrievability_desc second.
Why don’t you make simulations? See which combination does the best. I suppose that 5 sort orders, for 2 different slots, have (5 x 4 = ) 20 different possible permutations (taking the order of the sorts into account) (I am not the best in math).
The winners are (I think, idk what is the conclusion):
- Retrievability Descending
- Difficulty Ascending
- Difficulty Descending
- PRL
- PSG
So for example:
| Sort 1 | Sort 2 |
|---|---|
| Difficulty Asc | Retrievability Desc |
| PRL Desc | Retrievability Desc |
| Retrievability Desc | PRL Desc |
| Retrievability Desc | Difficulty Asc |
You choose the winners and try to find the best combination. I suppose this is what @Keks meant.
The second sort only makes sense for
Due date,
Deck,
For the rest, this is almost meaningless, since you will almost never have cases when the cards will claim the same position in the first sorting.
1 Like