refactor(req): model items as totally ordered values - #244
Merged
Conversation
Member
Author
|
in sync @pmcgleenon |
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.
Summary
Clone + Ordfor the in-memory REQ algorithm, matching the paper's totally ordered item universeReqValuelimited to optional serialization, so custom ordered types can use in-memory APIs without a codecReqFloat<f32/f64>for non-NaN numeric ordering, with signed zeros equal and infinities ordered numericallyReqFloatthroughout the user-facing REQ behavior testsRationale
Relative Error Streaming Quantiles defines REQ over a totally ordered universe. The algorithm sorts compaction ranges and its rank definition relies on that same order.
PartialOrdplus a self-comparison check does not express this requirement: a value can compare with itself while remaining incomparable with another value.The generic core therefore uses Rust's standard
Ordcontract directly. There is no REQ-specific comparison trait, comparator policy, default policy type, or external dependency. Primitive floats do not implementOrdbecause NaN is unordered, soReqFloatrejects NaN at construction and makes the algorithm's ordering precondition explicit.Adapter scope
ReqFloatintentionally forwards only invariant-preserving, high-value read operations:into_innerfor ownership recoveryDereffor float methods and borrowed accessDebugandDisplayIt does not implement
DerefMut, unconditional conversion from a primitive float, or arithmetic operators. Those APIs could bypass the NaN check or require a large family of potentially panicking forwarding implementations when an operation produces NaN. Callers can extract the primitive explicitly when they need unrestricted float behavior.API impact
ReqSketch<T>andSortedView<T>requireT: Clone + Ord.f32/f64sketches becomeReqSketch<ReqFloat<f32/f64>>.ReqValue;ReqFloatuses the same raw float bytes and rejects NaN images during deserialization.Size
No dependency or policy layer was added. The complete PR is 584 insertions and 537 deletions relative to
main(net +47 lines); the net addition is module/API documentation plus explicit float use in existing tests.Tests
ReqFloat<f32/f64>Clone + Ordvalues use in-memory APIs without implementingReqValuecargo x checkcargo x testcargo x lint