Expertium
Expertium
Well, my new definition of D improves RMSE by 2%, but it adds a lot of new parameters and is incompatible with short-term scheduling since R=100% for same-day reviews. One...
@L-M-Sherlock So here's my idea for short-term scheduling: 1) Add a new parameter that scales real time to convert it into "psychological" time. It should be equal to 1 for...
@L-M-Sherlock once you have some free time, I would like you to benchmark my suggestion in the comment above. Maybe with one minor change: ``` time_scaling = torch.where(X[:, 0] <...
Maybe add more parameters? If you're planning to include this in the next major version of FSRS, then why not?
https://github.com/fasiha/ebisu.js/issues/23 I suggested that, but it seems that LMSherlock and @fasiha just kinda weren't very interested.
> Part of the reason is, Ebisu and its benchmarks handle not just binary quizzes but also binomial and noisy-binary and passive quizzes; and it’s not been obvious how to...
> if we’re targeting 90% retrievability, we should _expect_ to miss 10% of items, even if their underlying stabilities are identical. Most algorithms handle that with an ad-hoc solution (eg...
@fasiha we're working on FSRS-5, and I will make another Reddit post about benchmarking, so if you are still interested, you can come back to implementing Ebisu in the benchmark.
  These 2 are the weirdest. The other ones may simply be too noisy, but these two have a clear pattern: R goes **up** as time passes.  
A bit unrelated to the current issue, but I wonder if we should change this: ``` for small_rating, big_rating in ( (1, 2), (2, 3), (3, 4), (1, 3), (2,...