Repository navigation
docs: f64 delta receivers match the producer only up to rounding - #255
Merged
Merged
Conversation
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
zzylol
marked this pull request as ready for review
October 29, 2026 00:41
zzylol
force-pushed
the
docs/f64-delta-rounding
branch
from
October 29, 2026 00:41
7fb0552 to
39861bf
Compare
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
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.
Part of #250
Why
Issue #250 lists CMS / Count Sketch
f64counters:old + (new - old)can missnewby rounding. Example:old = 1.0,new = 1e-17; the deltanew - oldrounds to-1.0, so the receiver holds0.0, not1e-17. This is inherent to floating point, so it is documented as a bounded limitation, not changed.What
docs/asapv1_wire_format.md§3.23: new "Exactness of a receiver" paragraph.i32/i64receivers equal the producer exactly;f64receivers equal it up to rounding, with the bound below.DeltaCounterdoc comment (src/asapv1/delta.rs) and the Deltas section of the Count-Min, Count Sketch, CountMinSketchWithHeap and CountSketchWithHeap API pages state the same.src/sketches/countminsketch/delta.rs; CHANGELOG entry (Docs).How
Bound (u = 2^-53, finite values): each apply is one add rounded to nearest, off by at most
u*|result|. Afternapplies from an equal start the cell differs by at most the sum ofe_i + u*|r_i|, wheree_iis how far deltaiis from the producer's true change. A producer formingd_i = new - oldof its ownf64cells hase_i <= u*|d_i|, giving at most2*n*u*M; one summing updates in a separate buffer carries that buffer's error ine_i. Integer-valued f64 cells below 2^53 are exact too. The API pages say each apply adds at mostu*|result|on top of the error the delta already carries. Heaps are replaced, not added, so carry no such error. Octo's emitted cell deltas are integer (count as i32) and are not affected.Before / After
Before: nothing said a receiver may differ. After: the limitation and bound are stated and tested. No behavior change, no deletions.
Verification
cargo test --lib countminsketch::delta: 6 passed, includingf64_receiver_differs_from_producer_within_the_documented_bound(concrete miss, plus a seeded 1000-apply sequence of mixed-magnitude, mixed-sign cell values that asserts error > 0 and within the summed bound) andinteger_receiver_equals_producer_exactly.cargo fmt --check,cargo clippy --all-targetswith and without--features experimental: clean.Limitations
The test sits in the Count-Min module; Count Sketch shares
add_cells, so the same arithmetic applies. The bound assumes every cell, delta and sum is finite (the decoder accepts inf/NaN f64 deltas, and an add can overflow to inf).🤖 Generated with Claude Code