Conversation
node-solid-server keeps a decimal such as "1.0"^^xsd:decimal as "1", but
serves it back as the Turtle shorthand 1.0. A later PATCH that deletes
the value as read, "1.0", finds nothing to delete there and fails with
409. Deletions now spell a whole-number decimal as the integer it is
("1"), which every server tested deletes as stored, and which is how the
app writes it itself. Insertions are sent as they are.
No decimal the app wrote so far was a whole number; FSRS's difficulty,
clamped to 1 and 10, will be.
fsrs.ts is FSRS-7, the Free Spaced Repetition Scheduler's dual-trace model, ported from ts-fsrs (itself a port of fsrs-rs): the memory after an answer given any fractional number of days after the last, the probability of recall, the interval for a desired retention (Newton steps, then bisection), and a memory estimated from an SM-2 interval for a prompt FSRS has not seen (fsrs-rs's memory_state_from_sm2, which for FSRS-7 uses no ease factor). The domain imports no vendor code, so the formulas are ported rather than imported. scripts/generateFsrsVectors.ts writes test vectors with ts-fsrs, pinned exactly as a root dev dependency (6.0.0-beta.13, the first releases with FSRS-7): 36 sequences of answers over the default weights and two perturbed sets, at elapsed times from seconds to years. The port matches every memory and retrievability to nine significant digits, and every interval to six. Nothing uses the port yet.
Every answer now moves both algorithms on (nextReviewState): SM-2's ease and repetitions, and FSRS-7's memory, given the exact time since the prompt's last answer. The instance's scheduler alone decides the interval, so switching takes effect at the next review, either way. A prompt FSRS has not seen gets a memory estimated from its SM-2 interval first. FSRS's interval is the time until recall falls to the desired retention, fuzzed, kept in order across ratings, and at least a day: a card forgotten today comes back within the session, not on another day. Review-state format 3 adds the memory (sm:stability, sm:stabilityFast, sm:difficulty) and the same in the undo snapshot, each all or nothing; the step from format 2 changes nothing. Preferences format 4 adds sm:scheduler, a concept of the new sm:Schedulers scheme, and sm:desiredRetention (0.70 to 0.97); the step from format 3 keeps SM-2. A new instance's preferences are written at creation: FSRS, with the Again/Hard/Good/Easy scale. An instance without preferences still studies by SM-2, so nobody is rescheduled unasked. The preferences screen chooses the scheduler and the desired retention, and, once FSRS is saved, offers to reschedule every reviewed prompt's due day as FSRS would have set it (rescheduleWithFsrs), after a confirmation, saying how many moved sooner and later. Resetting a study day restores the morning's memory. The repair of a half-written snapshot also covers a half-written memory, which format 3 reports through sh:and. An end-to-end test runs FSRS reviews, a reset and a reschedule on every blocking server.
# Conflicts: # docs/boundaries.md # packages/application/src/useCases.ts
ixuz
marked this pull request as draft
October 3, 2026 20:19
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Before this can merge: FSRS-7 upstream readiness
This PR schedules with a port of FSRS-7 checked against
ts-fsrs@6.0.0-beta.13(pinned exactly, used only to generate test vectors). FSRS-7 is not yet in a stable release, so this stays a draft until the items below are done.Blocking
main; the latest release, v6.6.2, has none of it. fsrs-rs is the reference ts-fsrs's FSRS-7 is checked against. How FSRS model versions will map to crate versions is open in fsrs-rs#446.Watch (does not affect the default weights this PR ships with)
w[26]. Matters only once we fit personal weights (planned follow-up).Already resolved upstream (for context)
memoryFromSm2ports the fixed version.Then, in this PR
ts-fsrsin the rootpackage.jsonto the stable release, runnode scripts/generateFsrsVectors.ts, and review any change inpackages/domain/src/testing/fsrsVectors.ts. A change means the formulas moved after the beta: updatepackages/domain/src/fsrs.ts, and decide whether review-state format 3 still describes the stored memory.npm run checkand the blocking pod suite (npm run test:pod).