[Feature request] A quantitative measure of cheating about srs-benchmark HOT 9 CLOSED

Why not use the variance of p? Cheating algorithms tend to provide a small range of predictions, so the variance would be small, too.

from srs-benchmark.

I think my measure is more intuitive. You can add both if you want to, you'll have to re-run the benchmark anyway.

from srs-benchmark.

I find out a typical cheating case:

When the algorithm is measured by itself, FSRS-4.5 is worse than DASH[ACT-R]. But when they are measured by each other, FSRS-4.5 is better than DASH[ACT-R]. Anyway, the log loss is uncheatable.

Here are their calibration graphs.

FSRS-4.5:

DASH[ACT-R]:

from srs-benchmark.

Yes, but we have to do this for all 20 000 collections and compare averages. We can't deicde whether an algorithm is cheating or not based on one collection.
I would suggest implementing both my original suggestion and your stdev of p.

from srs-benchmark.

The main problem is we don't know the real distribution of retrievability. The ideas of you and me both assume that the real distribution is more flat than the distribution predicted by a cheat algorithm.

from srs-benchmark.

True. Well, do you think DASH[ACT-R] should be included in the table now?
EDIT: I think it's reasonable to assume that the true distribution is a beta distribution.

The thing is, beta distribution can look like what we're seeing with ACT-R, depending on alpha and beta. We could also add UM (as the third metric), with FSRS-4.5 as comparison, but that would be difficult to interpret.

from srs-benchmark.

Btw, don't forget about #55

from srs-benchmark.

Well, do you think DASH[ACT-R] should be included in the table now?

If we still rank models by RMSE(bins), I tend not to include it. If we rank models by log loss, I will include it.

from srs-benchmark.

Hmmm. Ok, let's sort by log-loss then.

from srs-benchmark.