-
Notifications
You must be signed in to change notification settings - Fork 834
fix: Summary quantiles collapsing for targeted quantiles with 2*epsilon >= 1-quantile #2396
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
olegkovalenko
wants to merge
2
commits into
prometheus:main
Choose a base branch
from
olegkovalenko:fix-targeted-quantile-collapse
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+258
−21
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This nearest-center selection does not preserve the documented
q ± epsilonerror bound. On this head, inserting1..257shuffled withnew Random(5)into a singleQuantile(0.5, 0.025)returns rank 121, outside the allowed [122, 135] range;mainreturns rank 132. The test helper currently checksq ± 2*epsilon, masking the regression. Please preserve the publicq ± epsilonguarantee and tighten the regression assertions accordingly.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks — confirmed. Your case reproduces exactly (returns 121, allowed [122, 135]), and the
nearest-center selection was the culprit: a wide sample whose interval center happens to fall near
the desired rank could beat a narrow sample slightly further away.
Fixed by selecting the sample that minimizes the worst-case rank error instead: the true rank
of a sample is somewhere in
[r+g, r+g+delta], so the worst-case error of picking it ismax(|r+g − desired|, |r+g+delta − desired|), which equals the distance of the interval's centerfrom the desired rank plus half the interval's width. This penalizes wide samples; your case now
returns 132. I also tightened
validateResultsto the documentedq ± epsilonbound (floor/ceil,since ranks are integers) and added your case as a regression test (
testMedianSmallN).Two findings from verifying this that are worth flagging:
The
2 * epsilonhelper wasn't introduced in this PR — it's inherited frommain'svalidateResults, and it appears to exist becausemaindoesn't meet the strictq ± epsilonbound either. Sweeping main's unmodified code over values 1..n (true rank = value) across 10
configurations × sizes {100, 257, 1k, 10k, 100k} × 100 shuffled seeds: main exceeds 1ε on
dozens of shuffled cases, including your exact configuration
(0.5, 0.025)at other seeds —e.g. n=10,000 with
Random(47),Random(52), orRandom(77), up to 1.11ε. (The mechanism:deltas are fixed at insert time while n grows, so the paper's invariant erodes over the
sketch's lifetime.) With the selection rule above, this branch passes all of those shuffled
and ascending cases at 1ε — every case main passes and every case it fails.
The remaining known gap is descending input at large n: up to 1.75ε observed (configuration
(0.99, 0.005), n=100k). main exceeds 1ε on every descending case tested as well — by up to198ε on the collapsing configurations and ~1.1–1.25ε even on well-behaved ones — so this is
not a regression, but the strict bound genuinely doesn't hold there for either implementation:
sample widths are bounded when created, but with descending input a sample's rank grows by 1
per insert while the accuracy windows move right by less than 1 per insert, so old samples
drift toward the windows and their width bound erodes. A new
testTargetedQuantilesDescendingInputLargeNdocuments this and pins it to 2ε; all other testsnow assert 1ε. Making the strict bound hold under adversarial orderings would require
maintaining the invariant at query time — a much bigger change; happy to open a follow-up
issue for that if you think it's worth tracking.
On the evaluation grid from the PR description (2900 cases across configurations, distributions,
sizes, and seeds vs exact percentiles), the worst rank error improves from 1.78ε (nearest-center)
to 1.60ε with this rule, still with 0 cases above 2ε.