[BUG]: floating-point artefacts in tick labels #7765

Activity

1. jendrikw

   added

   bugsomething brokensomething broken

   on Apr 21, 2026
2. alexcjohnson commented on Apr 21, 2026

   

   alexcjohnson

   on Apr 21, 2026

   Collaborator

   More actions

   Thanks for the report! The default tickformat works fine, but ~r and some of the other d3-format specs show this behavior.

   In this case the behavior is clearly a bug, since you didn't specify tick0 so it defaults to 0 therefore it's unambiguous that the tick should be exactly at zero. And we could make a narrow fix that says "if the tick value is close to tick0 (much closer than whatever we've calculated as dtick), set it to exactly tick0. That would cover the 99% use case.

   The one case it wouldn't cover is if someone sets a nonzero tick0 but there's still a tick that should fall exactly on zero. Like tick0=1 and dtick=0.1. If we wanted to ensure we're robust in that situation, but still allow things that are not quite that to honor the user's intent like tick0=1.0001 and dtick=0.1, we'd need some sort of heuristic for how close to zero, as a fraction of dtick, counts as zero. One millionth? One billionth?
3. camdecoster commented on Apr 22, 2026

   

   camdecoster

   on Apr 22, 2026

   Contributor

   More actions

   Thanks for the report! This does indeed look like a bug. Our team likely won't have time to address this for a while, but can prioritize a PR review if you want to look into it.
4. camdecoster

   added

   good first issuesuitable for newcomerssuitable for newcomers

   on Apr 22, 2026
5. camdecoster

   closed this as completedin #7901on Jul 13, 2026
6. camdecoster

   added a commit that references this issue on Jul 13, 2026

   Snap near-zero tick values to tick0 to fix float artefacts in labels

   ...

   This issue will close once commit 0153c9e is merged into the 'main' branch.

   0153c9e