Bad case 1: very low initial stability

Solution: decrease the lower limit of w[0], w[1], w[2] and w[3] from 0.1 to 0.01.

from srs-benchmark.

Bad case 2: very long elapsed days for first reviews

Solution: filter out reviews with delta_t > 100.

from srs-benchmark.

Bad case 3: non-monotonous initial stability

The user's initial stability of good is lower than the initial stability of hard. And the data is enough.

Solution: don't compare initial stability with each other when the number of reviews is enough.

from srs-benchmark.

So do you think we should allow S0 to be non-monotonous? I think we shouldn't - users will be confused if, for example, their Easy interval is shorter than their Good interval.

from srs-benchmark.

It doesn't affect most users. And it could improve the accuracy of affected users significantly.

from srs-benchmark.

I think the confusion outweighs any accuracy benefits. @user1823, what do you think?

from srs-benchmark.

Solution: don't compare initial stability with each other when the number of reviews is enough.

Just like Expertium, I don't think that it is a good idea because interval for Good being less than Hard (or any other pair) would not be acceptable.

I think that in this case, the user has two (or more) different types of cards. So, more accurate parameters can be obtained if the user generates different parameters for different types of cards.

from srs-benchmark.

Solution: filter out reviews with delta_t > 100.

I agree that this makes sense for Again, Hard and Good, but probably not for Easy. For Easy, the limit should be higher. Perhaps 365 days?

from srs-benchmark.

OK. I reverted the solution of bad case 3 and relaxed the filter for bad case 1.

from srs-benchmark.