GeezerVison

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 ~r pass 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 ~r the 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