Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
On Sun, 8 May 2022 13:44:45 -0700 (PDT), Tabby <tabb...@gmail.com
wrote:
On Saturday, 30 April 2022 at 16:31:51 UTC+1, Skybuck Flying wrote:
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.
I can\'t remember where NAN is from, but it means the answer can not be computed.
Not A Number.
On Monday, May 2, 2022 at 11:54:53 AM UTC-4, Joe Gwinn wrote:
On Mon, 2 May 2022 15:28:46 +0100, Martin Brown
\'\'\'newspam\'\'\'@nonad.co.uk> wrote:
On 02/05/2022 15:10, jla...@highlandsniptechnology.com wrote:
On Sun, 1 May 2022 20:27:33 -0700 (PDT), whit3rd <whi...@gmail.com
wrote:
On Saturday, April 30, 2022 at 1:23:21 PM UTC-7, legg wrote:
On Sat, 30 Apr 2022 10:47:30 -0700 (PDT), Ricky
gnuarm.del...@gmail.com> wrote:
On Saturday, April 30, 2022 at 12:11:41 PM UTC-4,
jla...@highlandsniptechnology.com wrote:
I wrote an s32.32 saturating math package for the 68K that always did
what was most reasonable.
0/0 = 0
I\'m sure no one can explain why 0/0 = 0 makes sense. Zero does
not represent just exactly zero. Just as 1 is the range from 1/2 to
1-1/2, zero is the range from -1/2 to +1/2.
If the denominator is not zero, as the numerator approaches
zero, yes, in the limit, the result approaches zero. But if the
numerator is not zero, as the denominator approaches zero, in the limit,
the result approaches infinity. So why would 0/0=0 make sense?
I would have expected 0/0=1 ie no rational difference.
That\'s the case if you consider lim x/x as x approaches zero. But,
what of the limit of 2x/x, or -x/x, as x approaches zero? NAN is the
best way to get a thinking human to understanding what the computer
is trying to express.
What does a control system do when the heater voltage is computed to
be NAN?
Shut down. The situation should never arise if you have scaled the
problem correctly and you should never be dividing by zero anyway.
If the denominator of a division is zero then you haven\'t thought out
the representation of your problem correctly. Testing for zero is
usually quick (and often implicitly available in integer arithmetic).
Umm. Testing for zero doesn\'t necessarily change anything.
I have a war story here. Many decades ago, I was the software
architect for the mission software of a ship self defense system that
shoots incoming cruise missiles down, if it can. From detection at
the horizon to impact on ownship is maybe twenty seconds.
One fine day, a mob of software engineers turned up, locked in
argument about what to do if the engageability calculation suffered a
divide-by-zero exception.
This is not a coding error per se, it\'s a mathematical singularity in
the equations - some engagement geometries will hit the singularity,
and the embedded realtime computers of that day could not handle the
more complicated math needed to avoid such things fast enough to
matter.
There were two schools: Just provide a very large number and proceed,
praying. Stop and print out a bunch of diagnostic information.
Hmm. So the user, an ordinary sailor operating the self-defense
system is in the middle of an engagement with an incoming cruise
missile, and is suddenly handed a bunch or error messages, with less
than twenty seconds to live ... Really??? No! Just silently return
the best answer possible given the situation and press on, praying.
Was this because they could not use quaternions? I\'ve heard of 3D
calculations that are problematic because of issues in the math. They
solve that in 3 dimensional control by adding a forth coordinate,
quaternions, but obviously more calculations.
--
Rick C.
In article <90fb097e-85f0-4ca6-be35-b471d6498b32n@googlegroups.com>,
Ricky <gnuarm.deletethisbit@gmail.com> wrote:
On Monday, May 2, 2022 at 11:54:53 AM UTC-4, Joe Gwinn wrote:
On Mon, 2 May 2022 15:28:46 +0100, Martin Brown
\'\'\'newspam\'\'\'@nonad.co.uk> wrote:
On 02/05/2022 15:10, jla...@highlandsniptechnology.com wrote:
On Sun, 1 May 2022 20:27:33 -0700 (PDT), whit3rd <whi...@gmail.com
wrote:
On Saturday, April 30, 2022 at 1:23:21 PM UTC-7, legg wrote:
On Sat, 30 Apr 2022 10:47:30 -0700 (PDT), Ricky
gnuarm.del...@gmail.com> wrote:
On Saturday, April 30, 2022 at 12:11:41 PM UTC-4,
jla...@highlandsniptechnology.com wrote:
I wrote an s32.32 saturating math package for the 68K that always did
what was most reasonable.
0/0 = 0
I\'m sure no one can explain why 0/0 = 0 makes sense. Zero does
not represent just exactly zero. Just as 1 is the range from 1/2 to
1-1/2, zero is the range from -1/2 to +1/2.
If the denominator is not zero, as the numerator approaches
zero, yes, in the limit, the result approaches zero. But if the
numerator is not zero, as the denominator approaches zero, in the limit,
the result approaches infinity. So why would 0/0=0 make sense?
I would have expected 0/0=1 ie no rational difference.
That\'s the case if you consider lim x/x as x approaches zero. But,
what of the limit of 2x/x, or -x/x, as x approaches zero? NAN is the
best way to get a thinking human to understanding what the computer
is trying to express.
What does a control system do when the heater voltage is computed to
be NAN?
Shut down. The situation should never arise if you have scaled the
problem correctly and you should never be dividing by zero anyway.
If the denominator of a division is zero then you haven\'t thought out
the representation of your problem correctly. Testing for zero is
usually quick (and often implicitly available in integer arithmetic).
Umm. Testing for zero doesn\'t necessarily change anything.
I have a war story here. Many decades ago, I was the software
architect for the mission software of a ship self defense system that
shoots incoming cruise missiles down, if it can. From detection at
the horizon to impact on ownship is maybe twenty seconds.
One fine day, a mob of software engineers turned up, locked in
argument about what to do if the engageability calculation suffered a
divide-by-zero exception.
This is not a coding error per se, it\'s a mathematical singularity in
the equations - some engagement geometries will hit the singularity,
and the embedded realtime computers of that day could not handle the
more complicated math needed to avoid such things fast enough to
matter.
There were two schools: Just provide a very large number and proceed,
praying. Stop and print out a bunch of diagnostic information.
Hmm. So the user, an ordinary sailor operating the self-defense
system is in the middle of an engagement with an incoming cruise
missile, and is suddenly handed a bunch or error messages, with less
than twenty seconds to live ... Really??? No! Just silently return
the best answer possible given the situation and press on, praying.
Was this because they could not use quaternions? I\'ve heard of 3D
calculations that are problematic because of issues in the math. They
solve that in 3 dimensional control by adding a forth coordinate,
quaternions, but obviously more calculations.
Approximately my thoughts. Incoming missiles is a geometric problem.
Dividing by zero comes about by applying goniometric formulae,
instead of using matrix algebra that doesn\'t have weird exceptions.
My bet is on incompetent software engineers.
On Saturday, April 30, 2022 at 12:11:41 PM UTC-4, jla...@highlandsniptechnology.com wrote:
On Sat, 30 Apr 2022 08:31:47 -0700 (PDT), Skybuck Flying
skybuc...@gmail.com> wrote:
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.
I wrote an s32.32 saturating math package for the 68K that always did
what was most reasonable.
0/0 = 0
I\'m sure no one can explain why 0/0 = 0 makes sense. Zero does not represent just exactly zero. Just as 1 is the range from 1/2 to 1-1/2, zero is the range from -1/2 to +1/2.
If the denominator is not zero, as the numerator approaches zero, yes, in the limit, the result approaches zero. But if the numerator is not zero, as the denominator approaches zero, in the limit, the result approaches infinity. So why would 0/0=0 make sense?
That is exactly why anything divided by zero is NAN in a good math package. If you want to produce a result for 0/0, then that should be hard coded with clear documentation of what is being done and why it is acceptable.
The rationale that, \"it works\" means it works for the cases tested. Very sloppy indeed.
On Saturday, April 30, 2022 at 1:47:35 PM UTC-4, Ricky wrote:
On Saturday, April 30, 2022 at 12:11:41 PM UTC-4, jla...@highlandsniptechnology.com wrote:
On Sat, 30 Apr 2022 08:31:47 -0700 (PDT), Skybuck Flying
skybuc...@gmail.com> wrote:
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.
I wrote an s32.32 saturating math package for the 68K that always did
what was most reasonable.
0/0 = 0
I\'m sure no one can explain why 0/0 = 0 makes sense. Zero does not represent just exactly zero. Just as 1 is the range from 1/2 to 1-1/2, zero is the range from -1/2 to +1/2.
If the denominator is not zero, as the numerator approaches zero, yes, in the limit, the result approaches zero. But if the numerator is not zero, as the denominator approaches zero, in the limit, the result approaches infinity. So why would 0/0=0 make sense?
That is exactly why anything divided by zero is NAN in a good math package. If you want to produce a result for 0/0, then that should be hard coded with clear documentation of what is being done and why it is acceptable.
The rationale that, \"it works\" means it works for the cases tested. Very sloppy indeed.
I encountered an issue where code divides by zero. In my test fixture four measurements are taken with one as a reference. The other three are converted to dB against the reference. There are hardware failures where all four measurements are zero and the three calculations produce NAN. The crosstalk test does not report a failure. Turns out the comparison operator F< returns a FALSE (not an error) when either of the inputs are NAN. So I reversed the operands and inverted the resulting flag so that now the default FALSE is a TRUE flagging an error.
Is there a convention, or is it part of the IEEE standard how NAN is handled in such comparisons?
mandag den 30. maj 2022 kl. 18.04.57 UTC+2 skrev Ricky:
On Saturday, April 30, 2022 at 1:47:35 PM UTC-4, Ricky wrote:
On Saturday, April 30, 2022 at 12:11:41 PM UTC-4, jla...@highlandsniptechnology.com wrote:
On Sat, 30 Apr 2022 08:31:47 -0700 (PDT), Skybuck Flying
skybuc...@gmail.com> wrote:
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.
I wrote an s32.32 saturating math package for the 68K that always did
what was most reasonable.
0/0 = 0
I\'m sure no one can explain why 0/0 = 0 makes sense. Zero does not represent just exactly zero. Just as 1 is the range from 1/2 to 1-1/2, zero is the range from -1/2 to +1/2.
If the denominator is not zero, as the numerator approaches zero, yes, in the limit, the result approaches zero. But if the numerator is not zero, as the denominator approaches zero, in the limit, the result approaches infinity. So why would 0/0=0 make sense?
That is exactly why anything divided by zero is NAN in a good math package. If you want to produce a result for 0/0, then that should be hard coded with clear documentation of what is being done and why it is acceptable..
The rationale that, \"it works\" means it works for the cases tested. Very sloppy indeed.
I encountered an issue where code divides by zero. In my test fixture four measurements are taken with one as a reference. The other three are converted to dB against the reference. There are hardware failures where all four measurements are zero and the three calculations produce NAN. The crosstalk test does not report a failure. Turns out the comparison operator F< returns a FALSE (not an error) when either of the inputs are NAN. So I reversed the operands and inverted the resulting flag so that now the default FALSE is a TRUE flagging an error.
Is there a convention, or is it part of the IEEE standard how NAN is handled in such comparisons?
https://en.wikipedia.org/wiki/NaN#Comparison_with_NaN