Fix floating-point artefacts in tick labels (snap near-zero ticks to tick0)#7901
Open
kirthi-b wants to merge 1 commit into
Open
Fix floating-point artefacts in tick labels (snap near-zero ticks to tick0)#7901kirthi-b wants to merge 1 commit into
kirthi-b wants to merge 1 commit into
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
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
1 participant
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