-
Notifications
You must be signed in to change notification settings - Fork 287
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
linear.nice should use d3.tickIncrement for precise rounding. #81
Comments
Thanks for the report. I think we can fix this without too much trouble. This will affect both d3-array and d3-scale, since the core tick methods are in d3-array, but the implementation of linear.nice will be affected. Rather than tracking this in both places, let’s just use d3/d3-array#45. |
Just a heads up that I can still reproduce this issue with the latest version of d3-array (1.2.0). I expected d3/d3-array@04cf783 would solve the problem. Here are my dependencies:
|
No; linear scales still use d3.tickStep, not the new d3.tickIncrement, and so there’s no protection against rounding errors. See linear.js. However, I don’t see any reason why we couldn’t update linear.nice to use d3.tickIncrement and thus guarantee exact behavior (within the limits of IEEE 754). So I’ll reopen and retitle this issue accordingly. |
Say you want a nice linear scale and ticks for your
[5.83, 6.2]
domain.Due to float calculations .nice() sets the domain to:
and .ticks() returns:
Now you are missing the first 5.8 tick.
I know this happens because of float calculations (
0.05 * 116
), what is the best way to deal with the situation? Should it be solved by d3 or by a user?I ended up with rounding and resetting the domain with the help of d3.format, but looking for a more general solution.
The text was updated successfully, but these errors were encountered: