-
Notifications
You must be signed in to change notification settings - Fork 802
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
Return NaN coordinate immediately when receiving NaN input #949
Conversation
dd1b2be
to
a111d43
Compare
f760ded
to
ff89a5e
Compare
C99 has the function, lround, which rounds a double to a long returning
with
we would no longer have to include special tests for NaN. Of course for
@schwehr Could you verify that lround(NaN) is safe (doesn't cause the |
You mean rx = floor(x + 0.5);
ix = (int)rx;
ry = floor(y + 0.5);
iy = (int)ry;
rz = floor(z + 0.5);
iz = (int)rz; I am good with the |
Yes, I meant |
I get these cases from grepping a bit:
and then the rest of the
It is not a huge task to go through each of them and change them to behave as we want them to. I can do that one of the coming days. |
You will note that several of these (int) casts are actually rounds. Thus in geodesic.c
becomes the simpler
You still need to worry about how ties are handled (no problem in geodesic.c, however). And in this case, I don't need to worry about what arbitrary value gets returned with a NaN. |
Here's my implementation of lround...
|
e3df7a1
to
d9f0d6c
Compare
…n NaN input. Added test to check for those cases.
d9f0d6c
to
58cbb9f
Compare
7b7804b
to
dc1802e
Compare
dc1802e
to
6db260f
Compare
@cffk I finally got round to fixing the build errors in this. I plan on merging this tomorrow so that it can be included in PROJ 5.1.0RC1 (which I intend to release tomorrow afternoon CEST). If you have the time, could you give this a quick look and check if everything is sane? There's some stupid things regarding |
Replacing |
With http://c-faq.com/fp/round.html in mind, I think the cases in
becomes
The original intension must have been to round the numbers to the nearest integer value. |
Indeed.. The problem is now how ties are treated: |
Originally the code was doing double to int conversions like y = (int)(x + 0.5) which results in rounding when typecasting. In an earlier attempt to avoid buffer overflows in integer typecasts this was changed to y = lround(x + 0.5) which doesn't give the origial results. We fix that here by instead doing y = lround(x) It is safe to so as long as x is positive.
I have checked all of the cases and I believe they are all cases of positive numbers, so this should be safe. |
OK, looks good. |
Awesome. Thanks for supervising this! |
Ideally NaNs shouldn't get special treatment but since double to int
conversion is undefined behavior we are forced to treat NaNs as
something special. Therefor we return a NaN coordinate when ever we
encounter a NaN in one of the dimensions of an input coordinate. The
error level is not changed since this all math operations on NaNs should
return a NaN.
This policy of returning NaNs immediately should also eliminate a bunch
of potential double to int conversion bugs.
Alternative version of #943