Due Column - Changing Days (from Whole Numbers to Decimals in Scheduling)

@dae

Hello Dae. If you are reading this, I hope this suggestion interests you.

I suggest changing the representation of intervals as decimals instead of whole numbers (to account for hours, minutes, and seconds) so that:

  • It prevents clamping learning cards at 100% retrievability

(which makes little sense, since the nature of forgetting cards means that we start to forget things the moment we do not view the material - @Khonkhortisan even argues it does not always have to be 100% Retrievability the moment we view the card)

  • It allows FSRS to use its short-term scheduling fully so that it works with its forgetting curves and not in spite of it
1 Like

@dae I also would like to hear your thoughts, with technical details

1 Like

The technical details:

“345 results in 64 files”

It’s a nightmare to check the impact of Changing Days from Whole Numbers to Decimals.

And it also means we need to change inteval.

“253 results in 46 files”

Fine, it’s less than due.

1 Like

It is.

Also, I believe we need to wait and see how short-term scheduling is working for users before more effort is spent on things like this.

I think I have said this before but I don’t like the new feature (unexpectedly). It gives me intervals that are multiple days long instead of sub-day intervals. My performance with sub-day intervals is already horrible so I don’t know how logical >1d intervals are for learn state cards.

Can’t we calculate real same-day intervals without changing the current scheduling code?

Here’s what I mean. In order to calculate real interval lengths, we need the datetime info from revlogs.
image
If you can find a way to access that info, then the real interval length can be calculated, and then the usual (or modified with a new parameter for same-day intervals) formula can be used to calculate R. And then the same scheduling code that is currently used to schedule same-day reviews with FSRS-5 will be used.
We don’t actually need to change how Anki schedules reviews based on “days”, we just need to change what data is fed into FSRS.

If getting that info from revlogs is impossible, then I guess there’s nothing that ca be done, other than rewriting a whole lot of code.

I’m guessing accessing the data form revlogs is impossible.

It is actually possible. You just need to store the id of the last revlog entry in the card table, possibly in the data column.

This will need to be done either

  • at the time of the review (requires a minor modification to Anki’s Rust code)
  • after the review (can be easily done by an add-on).
  • at the time of the review (requires a minor modification to Anki’s Rust code)

So why wasn’t this proposed when FSRS-5 was being developed and integrated into Anki?

Well, I didn’t get the idea then. I got the idea after seeing Jarrett’s proposal in Set Due Date doesn't update the interval of card - #3 by L.M.Sherlock today.

If someone implements this, we will kill two birds with one stone. We will be able to calculate R accurately when sorting cards during review and we will be able to calculate the exact time elapsed since the last same-day review.

1 Like

Well, I guess it’s too late then. FSRS-5 is already developed AND integrated into Anki, and Jarrett wants to take a break. So FSRS-5.5 or whatever you wanna call it, with accurate same-day intervals, will have to wait for at least a year, possibly longer.

I thought I’ll ignore this but same-day reviews are important to me. I have changed (and plan to do more) my learning steps and it’s unfortunate that now FSRS treats my 1m 5m step the same as 1m 10m step.

@L.M.Sherlock might you be willing to consider whether this is worth implementing?

1 Like

We need to benchmark it first. I already pinged him on Discord and told him to give me the Anki 10k dataset with fractional interval lengths. I’ll see if I can make a version of FSRS that is more accurate than FSRS-5 while using fractional interval lengths. Well, assuming he will provide me with the dataset.

For now my roadmap is like this:

  1. Work on incorporating sibling reviews (need a modified dataset from Jarrett)
  2. Work on incorportating fractional interval lengths (need another modified dataset from Jarrett)
  3. If both are good, combine both into the same model (would need another modified dataset from Jarrett, with both changes)
  4. Jarret makes FSRS-6 and releases it in late 2025-early 2026
1 Like

The current dataset has included it:

Yes, but I need you to recalculate them so that they are expressed as days.

such that same-day reviews have an interval length between 0 and 1

elapsed_seconds / 86400 is what you need.

2 Likes

I’ve mentioned this before, but I think you could keep integers as the data type and use minutes instead of days as the unit of measure. Just to give a few responses to people who objected:

  • I think keeping the notion of Relearning steps is beneficial. Cards that come due in the Relearning phase should go to the front of the line.
  • Cards scheduled with an interval of < 24 hours would have the Relearning status. If the Relearn interval goes past into the next day, I think that’s fine, but another alternative is that those just convert to review cards (kinda like relearning steps over 12 hours do now).
  • People didn’t like the idea that reviews would be showing up at all times of the day if they’re scheduled to the resolution of minutes. You could just set reviews that are scheduled in a day to all show up for review at the start of the day. Use a floor() function.

This depends on what the actual difficulty here is. If the difficulty is converting an integer type to a float or double type, than changing to minutes for units would bypass that issue. I don’t know the code well enough to know what other nightmare problems that would pose though.

2 Likes

All the stats and graphs would need to be in days still, because that’s what makes the most sense for people to look at, but that’s very easy to convert.

1 Like

Give it a chance. I’ve noticed I look at cards a little more thoughtfully now that I know I won’t be seeing them in 10 minutes again. Also, it’s such a relief that cards aren’t piling up today when I get them wrong. If the deck says I have 100 reviews, that’s what I actually have, not 120+ with all the relearning cards.

I’d be curious if your experience changes over time. Has it changed in the past few weeks?

The original suggestion feels like an XY issue, but perhaps I have not understood the goal here. @L.M.Sherlock, could you summarise the problem you’re wanting to solve? I gather it’s about getting an accurate record of the elapsed time since last review? That can’t be done by consulting the revlog times?

Yes.

The information from the revlog table can’t be accessed at the time of review. Can it be?

The post is not written by me. I hope @DerIshmaelite could give a summary.