A bad case where the interval may go backwards due to fuzz

[L-M-Sherlock]

Even when the stability increased, the last interval still went backwards from 4 days to 3 days:

After running several tests, I figured it out. Anki forces good_interval >= hard_interval+1 and the second last hard interval was 2 days, so the good interval was 3 days. Due to fuzz, a 3 day interval can be 2, 3 or 4 days. In this case, it was 4 days.

After 4 days elapsed, the hard interval was still 2 days, and the good interval was 3 days, which was less than 4 days, so it didn't trigger the function to avoid fuzz to go backwards.

@user1823 please take a look.

[src/inference.rs:832:9] &next_states = NextStates {
    again: ItemState {
        memory: MemoryState {
            stability: 0.5836956,
            difficulty: 9.986542,
        },
        interval: 0.5836956,
    },
    hard: ItemState {
        memory: MemoryState {
            stability: 1.8026618,
            difficulty: 9.977774,
        },
        interval: 1.8026618,
    },
    good: ItemState {
        memory: MemoryState {
            stability: 1.9455183,
            difficulty: 9.969007,
        },
        interval: 1.9455183,
    },
    easy: ItemState {
        memory: MemoryState {
            stability: 3.0436015,
            difficulty: 9.960239,
        },
        interval: 3.0436015,
    },
}
[src/inference.rs:835:9] hard_interval = 2
[src/inference.rs:835:9] good_interval = 3
[src/inference.rs:837:9] fuzzed_good_interval = 4
[src/inference.rs:840:9] &next_states = NextStates {
    again: ItemState {
        memory: MemoryState {
            stability: 0.75977373,
            difficulty: 9.985005,
        },
        interval: 0.75977373,
    },
    hard: ItemState {
        memory: MemoryState {
            stability: 2.4843144,
            difficulty: 9.974718,
        },
        interval: 2.4843142,
    },
    good: ItemState {
        memory: MemoryState {
            stability: 2.7269485,
            difficulty: 9.96443,
        },
        interval: 2.7269483,
    },
    easy: ItemState {
        memory: MemoryState {
            stability: 4.591988,
            difficulty: 9.954142,
        },
        interval: 4.591988,
    },
}
[src/inference.rs:843:9] hard_interval = 2
[src/inference.rs:843:9] good_interval = 3

[user1823]

While writing the function to avoid fuzz to go backwards, I considered this case. However, I felt that it was difficult to solve and rarer than the general case (and so, less important).

To solve this, we should ideally compare the value of the previous interval before fuzzing. However, we can't accurately determine how much fuzz was applied the last time, and thus, can't know the value of the interval before fuzzing.

Another possible solution: In L185, replace interval with the upper limit of fuzz. But, this has the opposite problem: In some cases, it will cause the new interval to be higher than the previous one even if the unfuzzed new interval is not higher than the unfuzzed previous interval.

Any other solution is also welcome.

[JSchoreels]

However, we can't accurately determine how much fuzz was applied the last tim

Is it ? I remember reading in one of FSRS Helper Addon that seed was deterministic based on the seed and rep count. Can't we find that info back ?

[user1823]

We can use the unfuzzed interval to know the fuzzed interval, but I don't think this works in the reverse direction.

[L-M-Sherlock]

It's possible to know the fuzz factor used by the last review. However, the load balancer doesn't use fuzz factor. It uses fuzz seed in a very complicated way. It's impossible to recover the detail context of the last review.

[JSchoreels]

Okok ... Another idea : Aren't the FSRS params soon stored for each cards ? So we could recompute what the last stability was ? I guess we miss the DR at the time of review though ...

[apsen-github]

While writing the function to avoid fuzz to go backwards, I considered this case. However, I felt that it was difficult to solve and rarer than the general case (and so, less important).

To solve this, we should ideally compare the value of the previous interval before fuzzing. However, we can't accurately determine how much fuzz was applied the last time, and thus, can't know the value of the interval before fuzzing.

Another possible solution: In L185, replace interval with the upper limit of fuzz. But, this has the opposite problem: In some cases, it will cause the new interval to be higher than the previous one even if the unfuzzed new interval is not higher than the unfuzzed previous interval.

Any other solution is also welcome.

You do not need to know the last fuzz - just check the last interval and if it is within the current fuzz range, replace the lower fuzz limit with the old interval. Or, if the answer is 'good' or 'easy', just take whichever value is higher - the newly computed fuzzed interval or the last interval.

[apsen-github]

This is pretty wild swing 4->8->4

[apsen-github]

Or, maybe, it means there's too much fuzz currently...

Point in case: Interval going up significantly on answering 'Hard'

[user1823]

just check the last interval and if it is within the current fuzz range, replace the lower fuzz limit with the old interval.

This is just another way of saying what I already proposed above (In L185, replace interval with the upper limit of fuzz).

Now, I think that it is probably better to implement this and prevent noticeable instability (the fluctuating intervals) than to worry about the bias towards higher values in the fuzz range that this change will introduce. I will make a PR in the next few days.

As Danika said in the Anki Forum, it doesn't matter much what specific interval the card gets. Its stability and, thus, the interval will (roughly) be the same after a subsequent review. The main goal of this patch would be to avoid confusion. The impact on your workload will be minimal. Your workload is currently high because FSRS thinks that the material is difficult for you to remember, not because fuzz is sometimes causing the intervals to go backward.

if the answer is 'good' or 'easy', just take whichever value is higher

This is not the desirable behavior because if the user increases their desired retention significantly, this will prevent the intervals from shortening, thus, making the user unable to achieve the higher retention rates.

Or, maybe, it means there's too much fuzz currently...

This problem shows up only in the high difficulty cards whose intervals grow very slowly. Otherwise, the fuzz doesn't cause any problems and helps to prevent related cards from always showing up together. So, I don't think that we need to reduce the fuzz.