Commit 3f70312
fix: snap tick values to grid before applying custom tickformat
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 #77651 parent 1dc8553 commit 3f70312
2 files changed
Lines changed: 38 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
2189 | 2189 | | |
2190 | 2190 | | |
2191 | 2191 | | |
2192 | | - | |
| 2192 | + | |
| 2193 | + | |
| 2194 | + | |
| 2195 | + | |
| 2196 | + | |
| 2197 | + | |
| 2198 | + | |
| 2199 | + | |
| 2200 | + | |
| 2201 | + | |
| 2202 | + | |
| 2203 | + | |
2193 | 2204 | | |
2194 | 2205 | | |
2195 | 2206 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
18 | 18 | | |
19 | 19 | | |
20 | 20 | | |
| 21 | + | |
21 | 22 | | |
22 | 23 | | |
23 | 24 | | |
| |||
3888 | 3889 | | |
3889 | 3890 | | |
3890 | 3891 | | |
| 3892 | + | |
| 3893 | + | |
| 3894 | + | |
| 3895 | + | |
| 3896 | + | |
| 3897 | + | |
| 3898 | + | |
| 3899 | + | |
| 3900 | + | |
| 3901 | + | |
| 3902 | + | |
| 3903 | + | |
| 3904 | + | |
| 3905 | + | |
| 3906 | + | |
| 3907 | + | |
| 3908 | + | |
| 3909 | + | |
| 3910 | + | |
| 3911 | + | |
| 3912 | + | |
| 3913 | + | |
| 3914 | + | |
| 3915 | + | |
| 3916 | + | |
3891 | 3917 | | |
3892 | 3918 | | |
3893 | 3919 | | |
| |||
0 commit comments