Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
0.0 / 0.0 = -NAN ?
64 views
Skip to first unread message
Skybuck Flying
Apr 30, 2022, 11:31:09 AM4/30/22
to
When exception masks are all enabled to stop the processor from throwing floating point exceptions the following calculation produces a somewhat strange result:
0.0 / 0.0 = -nan
(At least in Delphi).
For now I will assume this is the case in C/C++ as well and with that I mean on x86/x64 which should and seems to be following IEEE 754 floating-point format.
I am a little bit surprised by this and I want/need to know more. Where is this defined that 0.0 / 0.0 should be -NAN ?!?
Problem is with the code, example:
T := 0;
D := 0.0 / 0.0;
P := T * D;
This screws up P. instead of P being zero, P is now also -NAN ?!?
I find this very strange but ok.
I guess a simple solution could be to set D to 0 explicitly for this case, is there perhaps another solution ? Maybe some kind of mask or rounding mode so that additional branch is not necessary ???
Bye for now,
Skybuck.
0.0 / 0.0 = -nan
(At least in Delphi).
For now I will assume this is the case in C/C++ as well and with that I mean on x86/x64 which should and seems to be following IEEE 754 floating-point format.
I am a little bit surprised by this and I want/need to know more. Where is this defined that 0.0 / 0.0 should be -NAN ?!?
Problem is with the code, example:
T := 0;
D := 0.0 / 0.0;
P := T * D;
This screws up P. instead of P being zero, P is now also -NAN ?!?
I find this very strange but ok.
I guess a simple solution could be to set D to 0 explicitly for this case, is there perhaps another solution ? Maybe some kind of mask or rounding mode so that additional branch is not necessary ???
Bye for now,
Skybuck.
Skybuck Flying
Apr 30, 2022, 1:34:14 PM4/30/22
to
In delphi it even depends on the platform.
Win32: 0.0 / 0.0 = -NAN
Win64: 0.0 / 0.0 = -1, #IND
Win32 sets FPU exception mask
Win64 sets SSE exception mask
(I believe I read somewhere that there are slight differences in FPU vs SSE floating point operations, but can't recall right now... something to maybe further look into... for now my tests have shown that the code I am working on currently works on both platforms...)
Just to be clear 0.0 for me at least simply means a 0 floating point number.
Though there is also +0.0 and -0.0 I think... and also -Infinity and +Infinity.
I would like to find some kind of specification or definition that goes deeper/explains why 0/0 produces these values ?!
Also these values seem to be "infectious" like a virus lol, it seems to be "propagated" through operations, so far multiplication, addition and comparison have been observed/witnessed ! ;)
Bye for now,
Skybuck.
Win32: 0.0 / 0.0 = -NAN
Win64: 0.0 / 0.0 = -1, #IND
Win32 sets FPU exception mask
Win64 sets SSE exception mask
(I believe I read somewhere that there are slight differences in FPU vs SSE floating point operations, but can't recall right now... something to maybe further look into... for now my tests have shown that the code I am working on currently works on both platforms...)
Just to be clear 0.0 for me at least simply means a 0 floating point number.
Though there is also +0.0 and -0.0 I think... and also -Infinity and +Infinity.
I would like to find some kind of specification or definition that goes deeper/explains why 0/0 produces these values ?!
Also these values seem to be "infectious" like a virus lol, it seems to be "propagated" through operations, so far multiplication, addition and comparison have been observed/witnessed ! ;)
Bye for now,
Skybuck.
Skybuck Flying
May 1, 2022, 10:13:12 PM5/1/22
to
I discovered another dangerous one while trying to compute overlap of interval (basically ranges) and/or trying to clip/cap line segments:
0 * +infinity = -NAN
This happens as the ray is on the edge of a boundary/box... cause tMinX will become -NAN.
Leading to weird situations depending on how the code was written, either the wrong point will be taken or it will not clip at all.
Once intersection segment with ray and box has been calculated, the ray segment has to be checked against the interestion segment to check if it overlaps... it's still possible it does not overlap.. for a "ray segment box intersection" algorithm. Analog to "line triangle intersection" algorithm, first "line plane intersection" then check if intersection point lies inside triangle which lies inside the plane.
I have seen some papers that try and work around these issues at least for ray/box intersection, but if these tricks work for ray segment box intersection remains to be seen.
Anyway best way to solve it is to use custom code for when delta x, y, or z is zero... instead of trying to divide or multiply by zero and infinity and such things cause certain combinations can lead to -NAN problems. Also win32 and win64 behave differently in delphi somewhat... perhaps 0 * infinity produces something else in win64... not yet sure...
It's in my video which I will upload shortly... hmmm...
Anyway... I am leaving math hell for now... leaving fpu hell... and returning back to the surface ! =D
Bye,
Skybuck =D
0 * +infinity = -NAN
This happens as the ray is on the edge of a boundary/box... cause tMinX will become -NAN.
Leading to weird situations depending on how the code was written, either the wrong point will be taken or it will not clip at all.
Once intersection segment with ray and box has been calculated, the ray segment has to be checked against the interestion segment to check if it overlaps... it's still possible it does not overlap.. for a "ray segment box intersection" algorithm. Analog to "line triangle intersection" algorithm, first "line plane intersection" then check if intersection point lies inside triangle which lies inside the plane.
I have seen some papers that try and work around these issues at least for ray/box intersection, but if these tricks work for ray segment box intersection remains to be seen.
Anyway best way to solve it is to use custom code for when delta x, y, or z is zero... instead of trying to divide or multiply by zero and infinity and such things cause certain combinations can lead to -NAN problems. Also win32 and win64 behave differently in delphi somewhat... perhaps 0 * infinity produces something else in win64... not yet sure...
It's in my video which I will upload shortly... hmmm...
Anyway... I am leaving math hell for now... leaving fpu hell... and returning back to the surface ! =D
Bye,
Skybuck =D
Skybuck Flying
May 1, 2022, 10:23:49 PM5/1/22
to
Little update:
This guy has an interesting take on it, basically saying 0 * infinity is the inverted case as 0 / 0, same kind of problem ! =D
https://math.stackexchange.com/questions/698690/when-0-is-multiplied-with-infinity-what-is-the-result
"
What I would say is that you can multiply any non-zero number by infinity and get either infinity or negative infinity as long as it isn't used in any mathematical proof. Because multiplying by infinity is the equivalent of dividing by 0. When you allow things like that in proofs you end up with nonsense like 1 = 0. Multiplying 0 by infinity is the equivalent of 0/0 which is undefined. –
PHP Guru
"
(Here will be my video: https://youtu.be/lAcneKBJ9zY in case anybody wants to see some math hell in action lol, doubt it :))
Bye,
Skybuck =D
This guy has an interesting take on it, basically saying 0 * infinity is the inverted case as 0 / 0, same kind of problem ! =D
https://math.stackexchange.com/questions/698690/when-0-is-multiplied-with-infinity-what-is-the-result
"
What I would say is that you can multiply any non-zero number by infinity and get either infinity or negative infinity as long as it isn't used in any mathematical proof. Because multiplying by infinity is the equivalent of dividing by 0. When you allow things like that in proofs you end up with nonsense like 1 = 0. Multiplying 0 by infinity is the equivalent of 0/0 which is undefined. –
PHP Guru
"
(Here will be my video: https://youtu.be/lAcneKBJ9zY in case anybody wants to see some math hell in action lol, doubt it :))
Bye,
Skybuck =D
0 new messages