fix: snap tick values to grid before applying custom tickformat#7810
Open
arieleli01212 wants to merge 1 commit into
Open
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
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 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.
Fixes #7765
What's wrong
When floating-point arithmetic leaves a tick value slightly off its true grid position — for example
-8.88e-16instead of0— 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 setstickformat(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
vto the nearest ideal tick positiontick0 + n * dtick. The tolerance is1e-9 × dtick, which is well below any deliberate non-zero tick value but comfortably above the floating-point noise that accumulates over a handful ofdtickadditions.The snap is only applied to non-hover labels (hover already independently recalculates its own rounding) and only when both
tick0anddtickare numeric (so date and log axes are unaffected).Changes
src/plots/cartesian/axes.js— snap insidenumFormatbefore thetickformatearly-returntest/jasmine/tests/axes_test.js— two cases:dtick: 0.5(the exact scenario from the issue) anddtick: 0.1(a dtick that itself accumulates FP error over several steps)