Fix floating-point artefacts in tick labels (snap near-zero ticks to tick0)#7901
Merged
camdecoster merged 4 commits intoJul 13, 2026
Merged
Conversation
When ticks are built by repeated increments, a tick that should sit exactly on tick0 can come out as a tiny nonzero value like -8.9e-17. The default numeric format rounds that away, but d3-format specs such as `~r` render it literally, so a tick at zero showed as -0.0000000000000000888178. When a computed tick value is far closer to tick0 than one dtick, snap it to exactly tick0. Fixes plotly#7765
camdecoster
approved these changes
Jul 13, 2026
camdecoster
left a comment
camdecoster
left a comment
Contributor
There was a problem hiding this comment.
Thanks for the PR! You're actually the third person to submit a PR for this issue, so I guess it's time I actually followed through on the review. Your initial solution to snap to tick0 was a good idea, but I decided to generalize it more to allow for snapping to a multiple of the tick delta (which is what the user that wrote #7810 was doing). I also added another test for a non-snap-to-zero case. Collaboration all around! Once CI passes I'll get this merged.
This was referenced Jul 13, 2026
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
2 participants
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.
What this fixes
Tick labels could show values like -0.0000000000000000888178 where the tick should read 0. Reported in #7765.
Why it happens
calcTicks builds tick values by repeated increments. With an unspecified tick0 (so it defaults to 0), a tick that should sit exactly on 0 can come out as a tiny nonzero value such as -8.9e-17 due to floating-point roundoff. The default numeric formatter rounds that away, but d3-format specs like
~rpass the value straight through and print it in full.The change
In calcTicks, when a computed tick value is far closer to tick0 than one dtick (within dtick times 1e-6), snap it to exactly tick0. This matches the narrow fix alexcjohnson outlined in the issue: with a default tick0 of 0 it is unambiguous that such a tick belongs at zero. It is limited to linear axes and numeric dtick, so date, log, and category axes are untouched.
Known limitation, same one noted in the issue: this snaps to tick0, so it does not cover the case where someone sets a nonzero tick0 but a tick still falls on zero (for example tick0=1, dtick=0.1). That would need a separate heuristic and is left out to keep this change small.
Test
Added a jasmine test in axes_test.js that builds the reproducing range ([-0.65, 0.65], tick0 0, dtick 0.2) and checks that with tickformat
~rthe zero tick renders as "0" rather than the artefact, and that the default format stays correct. Verified it fails without the source change and passes with it.Thanks to camdecoster for offering to prioritize review of a PR for this.
Fixes #7765