Issue with the number of parameters in FSRS-RS

[temeipu-offical]

https://github.com/open-spaced-repetition/fsrs4anki/wiki/The-Algorithm
This article suggests that FSRS-5 has 19 default parameters, while FSRS-RS uses FSRS-5.5 with 17 parameters, which seems contradictory. FSRS-RS-DART, however, has 19 parameters, suggesting a slightly newer version. Therefore, which library should I use: FSRS-RS or FSRS-RS-DART? Which library has a more recent version of FSRS? Furthermore, why are the version and code differences between these libraries so significant?

All the library versions I mentioned are the latest versions.

Below is the source code for FSRS-RS.benchmark.rs

pub fn criterion_benchmark(c: &mut Criterion) {
    let fsrs = FSRS::new(&[
        0.81497127,
        1.5411042,
        4.007436,
        9.045982,
        4.9264183,
        1.039322,
        0.93803364,
        0.0,
        1.5530516,
        0.10299722,
        0.9981442,
        2.210701,
        0.018248068,
        0.3422524,
        1.3384504,
        0.22278537,
        2.6646678,
    ])
    .unwrap();

    c.bench_function("next_states", |b| b.iter(|| black_box(next_states(&fsrs))));

    c.bench_function("current_retrievability", |b| {
        let state = MemoryState {
            stability: 51.344814,
            difficulty: 7.005062,
        };
        b.iter(|| {
            black_box(current_retrievability(
                black_box(state),
                black_box(21.0),
                black_box(FSRS6_DEFAULT_DECAY),
            ))
        })
    });

    {
        let mut single_group = c.benchmark_group("calc_mem");
        let n_cards = 1000;
        let n_reviews = 10;
        single_group.throughput(Throughput::Elements(n_cards));
        single_group.bench_function(
            format!("calc_mem n_cards={n_cards}, n_reviews={n_reviews}"),
            |b| b.iter(|| black_box(calc_mem(&fsrs, n_reviews, n_cards.try_into().unwrap()))),
        );
        single_group.finish();
    }

    {
        let mut batch_group = c.benchmark_group("calc_mem_batch");
        for n_cards in [1000, 10_000] {
            for n_reviews in [10, 100, 200] {
                batch_group.throughput(Throughput::Elements(n_cards));
                batch_group.bench_function(
                    format!("calc_mem_batch n_cards={n_cards}, n_reviews={n_reviews}"),
                    |b| {
                        b.iter(|| {
                            black_box(calc_mem_batch(
                                &fsrs,
                                n_reviews,
                                n_cards.try_into().unwrap(),
                            ))
                        })
                    },
                );
            }
        }
        batch_group.finish();
    }
}

[ishiko732]

fsrs-rs uses FSRS-6, which has 21 parameters.
When the parameter count is 19, it will be automatically migrated to 21 parameters.

fsrs-rs/src/parameter_clipper.rs

Lines 28 to 79 in ec5d1c7

	pub(crate) fn clip_parameters(
	parameters: &Parameters,
	num_relearning_steps: usize,
	enable_short_term: bool,
	) -> Vec<f32> {
	let mut parameters = parameters.to_vec();
	// PLS = w11 * D ^ -w12 * [(S + 1) ^ w13 - 1] * e ^ (w14 * (1 - R))
	// PLS * e ^ (num_relearning_steps * w17 * w18) should be <= S
	// Given D = 1, R = 0.7, S = 1, PLS is equal to w11 * (2 ^ w13 - 1) * e ^ (w14 * 0.3)
	// So num_relearning_steps * w17 * w18 + ln(w11) + ln(2 ^ w13 - 1) + w14 * 0.3 should be <= ln(1)
	// => num_relearning_steps * w17 * w18 <= - ln(w11) - ln(2 ^ w13 - 1) - w14 * 0.3
	// => w17 * w18 <= -[ln(w11) + ln(2 ^ w13 - 1) + w14 * 0.3] / num_relearning_steps
	let w17_w18_ceiling = if num_relearning_steps > 1 {
	(-(parameters[11].ln() + (2.0f32.powf(parameters[13]) - 1.0).ln() + parameters[14] * 0.3)
	/ num_relearning_steps as f32)
	.max(0.01)
	.sqrt()
	.min(2.0)
	} else {
	2.0
	};
	let w19_floor = if enable_short_term { 0.01 } else { 0.0 };
	// https://regex101.com/r/21mXNI/1
	let clamps: [(f32, f32); 21] = [
	(S_MIN, INIT_S_MAX),
	(S_MIN, INIT_S_MAX),
	(S_MIN, INIT_S_MAX),
	(S_MIN, INIT_S_MAX),
	(D_MIN, D_MAX),
	(0.001, 4.0),
	(0.001, 4.0),
	(0.001, 0.75),
	(0.0, 4.5),
	(0.0, 0.8),
	(0.001, 3.5),
	(0.001, 5.0),
	(0.001, 0.25),
	(0.001, 0.9),
	(0.0, 4.0),
	(0.0, 1.0),
	(1.0, 6.0),
	(0.0, w17_w18_ceiling),
	(0.0, w17_w18_ceiling),
	(w19_floor, 0.8),
	(0.1, 0.8),
	];
	parameters
	.iter_mut()
	.zip(clamps)
	.for_each(|(w, (low, high))| *w = w.clamp(low, high));
	parameters

[temeipu-offical]

I examined the source code and found that the optimizer requires the full log for each optimization session. This is because historical review records are not subject to further changes. Additionally, a review sequence must be generated from the review log prior to each optimization session. This sequence often grows exponentially, potentially leading to a sharp decline in performance when the volume of user review data becomes excessive. Therefore, it is worth considering whether optimized data can undergo incremental optimization, persisting some previous optimization results. This way, during each optimization session, we can simply start from the previous optimization point, eliminating the need to input already optimized logs. However, scenarios where users have deleted logs must be taken into account.
I don't know if the current optimizer has this issue and how it is addressed?

[L-M-Sherlock]

The current optimizer in fsrs-rs is stateless: compute_parameters always trains from scratch on the full Vec<FSRSItem> you pass in (src/training.rs). There’s no API to resume or incrementally update from prior results, and log deletions aren’t specially handled—whatever logs you supply become the training set. There is a hard cap on sequence length (items with history length > max_seq_len, default 1024, are dropped), but that’s not incremental optimization (src/training.rs, src/dataset.rs).

About growth: the converter used in the benchmark (and tests) creates n−1 items per card, each containing the full prefix history (src/convertor_tests.rs and the inlined copy in benches/parameters.rs). That makes total history length per card O(n^2), not exponential. Training time per epoch is proportional to the sum of all history lengths across items, so overall O(k·n^2) for k cards with n reviews each (capped by max_seq_len).

Benchmark coverage: there is a training benchmark in benches/parameters.rs that runs compute_parameters. You can download the test file here:

cargo bench --bench parameters

Results on my machine:

• compute_parameters: ~0.414 s (410.8–417.4 ms)
• evaluate_with_time_series_splits: ~1.12 s
• evaluate: ~70 ms

Dataset size used by that benchmark:

• Raw revlog rows read: 24,394
• FSRSItems produced: 14,290
• Total history length across items (sum of review counts): 95,680

So yes, the optimizer currently expects full data each time; no incremental optimization is implemented. The observed scaling issue is quadratic per card (from prefix histories), not exponential.