fix: snap tick values to grid before applying custom tickformat - #7810
Closed
arieleli01212 wants to merge 1 commit into
Closed
fix: snap tick values to grid before applying custom tickformat#7810arieleli01212 wants to merge 1 commit into
arieleli01212 wants to merge 1 commit into
Conversation
Copy link
Copy Markdown
Sorry, something went wrong.
When floating-point arithmetic produces a tick value that is slightly off its true position (e.g. -8.88e-16 instead of 0), the default formatter is immune because it adds an internal rounding epsilon before rendering. Custom d3 formats specified via tickformat (such as '~r') don't go through that path and expose the raw number, which can produce labels like '−0.0000000000000000888178' for a tick that should read '0'. Fix by snapping v to the nearest ideal tick position (tick0 + n*dtick) before passing it to the user's formatter, using a relative threshold of 1e-9 of dtick so only genuine floating-point noise is removed. Fixes plotly#7765
This was referenced Jul 13, 2026
Copy link
Copy Markdown
Contributor
|
Thanks for the PR! You and two others submitted fixes for the issue and I ended up combining some of your code into #7901 and merging that PR. As such, I'm going to close this one. Thanks for your contribution! |
Sorry, something went wrong.
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.
Fixes #7765
What's wrong
When floating-point arithmetic leaves a tick value slightly off its true grid position — for example -8.88e-16 instead of 0 — the result depends on which formatter is used. The built-in formatter is safe because it adds an internal rounding epsilon and then rounds to the computed number of significant digits. But when a user sets tickformat (e.g. '~r', '.4f') the value is passed straight to d3-format, which faithfully renders the raw float:
The fix
Before delegating to the user's formatter, snap v to the nearest ideal tick position tick0 + n * dtick. The tolerance is 1e-9 × dtick, which is well below any deliberate non-zero tick value but comfortably above the floating-point noise that accumulates over a handful of dtick additions.
The snap is only applied to non-hover labels (hover already independently recalculates its own rounding) and only when both tick0 and dtick are numeric (so date and log axes are unaffected).
Changes