-
Notifications
You must be signed in to change notification settings - Fork 187
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() ticks do not always span the domain #199
Comments
Using the d3-array API: d3.nice(0.98, 1.13, 10) // [0.98, 1.14]
d3.ticks(0.98, 1.14, 10) // [0.98, 1, 1.02, 1.04, 1.06, 1.08, 1.1, 1.12] Rounding to some arbitrary precision is not going to work in general. I think we might need to do something like this instead: step = -step;
start = Math.ceil(start * step);
const r = Math.round(stop * step);
stop = r - (r / step > stop); |
mbostock
added a commit
that referenced
this issue
Mar 23, 2021
Merged
I was unsure of the wider effect or use so makes sense it's not as simple as rounding. |
mbostock
added a commit
that referenced
this issue
Mar 24, 2021
* fix #199; avoid rounding error * remove noop ceil
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I believe this issue is a floating point number precision error in the d3-array/ticks
For this specific example and following the bouncing ball, if ticks is called with
(0.98, 1.14, 10)
then we get the following on line 23Naturally calling
floor
unintentionally reduces thestop
value by 1.PR #164 was added to solve #162 however I think it just inverted the issue.
In this scenario the precision is not important so I think a possible solution is to call
toPrecision()
or used3-format
?Happy to submit a PR after discussion.
Note:
This issue is more an issue for
d3-array
thand3-scale
but I have submitted it here as this is where the issue surfaced for me. Happy to close this and open one ford3-array
if required.Edit:
I note that most of the tests covering this are using integer domains and a relatively small count (2,3,4). If I call
check([0.98, 1.14], 2/3/4);
then they all pass but not withcount = 10;
(default).Should this test suit be expanded a little?
Second Edit:
On second thoughts
toPrecision
wouldn't work due to the unknown size of thestart
onstop
but possible something as simple as the following:There is possibly a wider issue/effect that I am unaware on but this patch does fix my issue and make all the test pass including that of
d3-array
.The text was updated successfully, but these errors were encountered: