-
Notifications
You must be signed in to change notification settings - Fork 311
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
Rounded corners on arc produces NaNs due to floating point imprecision #90
Comments
Fixed in #91; thank you. If you have time, I would appreciate a test to verify this fix as I am unable to reproduce it. |
@mbostock Great! Regarding the test case: unfortunately, because we're currently using v3 (and I'm now going to push moving to v4) and some of the maths above this line has changed and it's difficult to force floating point errors, I only have a case that produces 'NaN's in v3. However, the logic is of course the same - it's occurring because
which results in |
It’s possible this could not have occurred in v4 anyway because it uses epsilon to test for a number of boundary conditions. (Here, the angle of the arc is 3.3263922214480157 - 0.18479956785822316 = 3.1415926535897927 which is approximately π.) |
Ah apologies - so either my PR was unnecessary, or the |
Yep, happy to have this fix. Thank you! |
This line in
src/arc.js
assumes that the argument toMath.acos
is between -1 and 1, which is not always true due to floating point imprecision, resulting inNaN
s in the arc's path and preventing the arc from rendering.I have a fix for this (#91), which introduces clamped version of
acos
, but I would also very much appreciate if this could also be fixed in d3 v3 (where there is already ad3_acos
function to use). I'm not sure if pull requests are being accepted on v3.The text was updated successfully, but these errors were encountered: