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.
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,I wrote an s32.32 saturating math package for the 68K that always did
Skybuck.
what was most reasonable.
0/0 = 0
On Saturday, April 30, 2022 at 12:11:41 PM UTC-4, jla...@highlandsniptechnology.com wrote:make sense?
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:I wrote an s32.32 saturating math package for the 68K that always did
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.
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
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.
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 ?!?
On Sat, 30 Apr 2022 10:47:30 -0700 (PDT), Ricky <gnuarm.deletethisbit@gmail.com> 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 ???
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.
make sense?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
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 would have expected 0/0=1 ie no rational difference.
On Sat, 30 Apr 2022 10:47:30 -0700 (PDT), Ricky ><gnuarm.deletethisbit@gmail.com> wrote:make sense?
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:I wrote an s32.32 saturating math package for the 68K that always did
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.
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
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 would have expected 0/0=1 ie no rational difference.
RL
On Sat, 30 Apr 2022 10:47:30 -0700 (PDT), Rickymake sense?
<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
I would have expected 0/0=1 ie no rational difference.
I discovered another dangerous one while trying to compute overlap of interval (basically ranges) and/or trying to clip/cap line segments:to "line triangle intersection" algorithm, first "line plane intersection" then check if intersection point lies inside triangle which lies inside the plane.
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
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.differently in delphi somewhat... perhaps 0 * infinity produces something else in win64... not yet sure...
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
It's in my video which I will upload shortly... hmmm...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. –
Anyway... I am leaving math hell for now... leaving fpu hell... and returning back to the surface ! =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
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
On Saturday, April 30, 2022 at 1:23:21 PM UTC-7, legg wrote:make sense?
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
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.
On Sun, 1 May 2022 20:27:33 -0700 (PDT), whit3rd <whit3rd@gmail.com>make sense?
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
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?
On 02/05/2022 15:10, jlarkin@highlandsniptechnology.com wrote:make sense?
On Sun, 1 May 2022 20:27:33 -0700 (PDT), whit3rd <whit3rd@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
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).
On 02/05/2022 15:10, jlarkin@highlandsniptechnology.com wrote:make sense?
On Sun, 1 May 2022 20:27:33 -0700 (PDT), whit3rd <whit3rd@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
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).
On Mon, 2 May 2022 15:28:46 +0100, Martin Brown0 make sense?
<'''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=
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 outUmm. Testing for zero doesn't necessarily change anything.
the representation of your problem correctly. Testing for zero is
usually quick (and often implicitly available in integer arithmetic).
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.
On Mon, 2 May 2022 15:28:46 +0100, Martin Brownmake sense?
<'''newspam'''@nonad.co.uk> wrote:
On 02/05/2022 15:10, jlarkin@highlandsniptechnology.com wrote:
On Sun, 1 May 2022 20:27:33 -0700 (PDT), whit3rd <whit3rd@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
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.
Joe Gwinn
mandag den 2. maj 2022 kl. 17.54.53 UTC+2 skrev Joe Gwinn:0 make sense?
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=
Umm. Testing for zero doesn't necessarily change anything.
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).
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.
sorta like: <https://en.wikipedia.org/wiki/Battleshort>
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:
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?
On Monday, May 2, 2022 at 7:10:49 AM UTC-7, 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:
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?
The program writer decides. In general, switch from plan A computation of >intended heater voltage, to plan B.
The program ought to handle these cases in a way that is appropriate,
even if it is exceptional.
For a gas flame heater, you call the repairman when no amount of
ignition power is enough. For a car, you see an 'engine' light come on,
and drive (or tow) to a repair shop.
On Mon, 2 May 2022 15:28:46 +0100, Martin Brown0 make sense?
<'''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=
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 outUmm. Testing for zero doesn't necessarily change anything.
the representation of your problem correctly. Testing for zero is
usually quick (and often implicitly available in integer arithmetic).
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.
On Mon, 02 May 2022 11:54:32 -0400, Joe Gwinn <joeg...@comcast.net>0 make sense?
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=
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.
Joe GwinnYes. A best guess is better than an exception trap. Or a crash.
jla...@highlandsniptechnology.com wrote:make sense?
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
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 toLog it, skip the update, and press on to the next measurement.
be NAN?
On Sun, 1 May 2022 20:27:33 -0700 (PDT), whit3rd <whit3rd@gmail.com>make sense?
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
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?
mandag den 2. maj 2022 kl. 22.52.48 UTC+2 skrev Phil Hobbs:0 make sense?
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=
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.
hoping that that doesn't slow the system down to muchWhat does a control system do when the heater voltage is computed toLog it, skip the update, and press on to the next measurement.
be NAN?
On Monday, May 2, 2022 at 5:02:22 PM UTC-4, lang...@fonz.dk wrote:0=0 make sense?
mandag den 2. maj 2022 kl. 22.52.48 UTC+2 skrev Phil Hobbs:
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/
Screw that up and you will have a system that does what you asked for, but not what you want.
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.
If it does, it is a crappy system. That's what almost killed the first moon landing. You can test until you are blue in the face and you have not proven anything. You have to deal with these sorts of issues up front in the design requirements stage.hoping that that doesn't slow the system down to muchWhat does a control system do when the heater voltage is computed to be NAN?Log it, skip the update, and press on to the next measurement.
Thinking 0/0 is an ok thing to approximate is not a way to design critical systems.
On Sat, 30 Apr 2022 16:24:03 -0400, legg <legg@nospam.magma.ca> wrote:make sense?
On Sat, 30 Apr 2022 10:47:30 -0700 (PDT), Ricky >><gnuarm.deletethisbit@gmail.com> 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:I wrote an s32.32 saturating math package for the 68K that always did
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.
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
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 would have expected 0/0=1 ie no rational difference.
RL
0 is the safest heater power.
On Monday, May 2, 2022 at 11:54:53 AM UTC-4, Joe Gwinn wrote:0 make sense?
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=
Umm. Testing for zero doesn't necessarily change anything.
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).
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.
jlarkin@highlandsniptechnology.com wrote:make sense?
On Sun, 1 May 2022 20:27:33 -0700 (PDT), whit3rd <whit3rd@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
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?
Log it, skip the update, and press on to the next measurement.
Cheers
Phil Hobbs
On Sun, 01 May 2022 07:29:30 -0700, jlarkin@highlandsniptechnology.commake sense?
wrote:
On Sat, 30 Apr 2022 16:24:03 -0400, legg <legg@nospam.magma.ca> wrote:
On Sat, 30 Apr 2022 10:47:30 -0700 (PDT), Ricky >>><gnuarm.deletethisbit@gmail.com> 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:I wrote an s32.32 saturating math package for the 68K that always did >>>>> what was most reasonable.
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
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
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 would have expected 0/0=1 ie no rational difference.
RL
0 is the safest heater power.
Is that possible, if it's ON ?
If it's OFF and cooling, values should still look positive, as--
it's not the power application that is immediately responsible
for heat transfer.
RL
On Mon, 02 May 2022 18:23:38 -0400, legg <le...@nospam.magma.ca> wrote:
On Sun, 01 May 2022 07:29:30 -0700, jla...@highlandsniptechnology.com >wrote:
On Sat, 30 Apr 2022 16:24:03 -0400, legg <le...@nospam.magma.ca> wrote:
I would have expected 0/0=1 ie no rational difference.
0 is the safest heater power.
Is that possible, if it's ON ?
If we have a broken thermocouple, or some cable disconnected, or a
shorted mosfet, we want to kill heater power.
On Monday, May 2, 2022 at 5:01:46 PM UTC-7, John Larkin wrote:
On Mon, 02 May 2022 18:23:38 -0400, legg <le...@nospam.magma.ca> wrote:
On Sun, 01 May 2022 07:29:30 -0700, jla...@highlandsniptechnology.com >wrote:
On Sat, 30 Apr 2022 16:24:03 -0400, legg <le...@nospam.magma.ca> wrote:
I would have expected 0/0=1 ie no rational difference.0 is the safest heater power.
Is that possible, if it's ON ?
If we have a broken thermocouple, or some cable disconnected, or aThat comment belongs embedded in the code that handles NAN
shorted mosfet, we want to kill heater power.
for the particular case where it indicates a broken thermocouple.
Otherwise it's a write-only bit of a program, and hazard in future.
mandag den 2. maj 2022 kl. 22.52.48 UTC+2 skrev Phil Hobbs:make sense?
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
Log it, skip the update, and press on to the next measurement.
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?
hoping that that doesn't slow the system down to much
On Mon, 2 May 2022 16:52:35 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:make sense?
jlarkin@highlandsniptechnology.com wrote:
On Sun, 1 May 2022 20:27:33 -0700 (PDT), whit3rd <whit3rd@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
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?
Log it, skip the update, and press on to the next measurement.
Fine as long as I don't fry a few hundred kilobucks of gear.
These systems didn't have anywhere to log errors. If things got scary,
I'd shut down and light a red LED.
NAN wouldn't be useful. A saturating math package let me make range
checks when prudent, but not every step of every expression. No traps
to handle.
The s32.32 saturating math package was fun to write, in 68332
assembly. It was fast because it didn't need any normalizing. Well,
divide was a nuisance.
Integer in/out conversions were fast. As in zero.
John Larkin wrote:0 make sense?
On Mon, 2 May 2022 16:52:35 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:
jlarkin@highlandsniptechnology.com wrote:
On Sun, 1 May 2022 20:27:33 -0700 (PDT), whit3rd <whit3rd@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=
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?
Log it, skip the update, and press on to the next measurement.
Fine as long as I don't fry a few hundred kilobucks of gear.
These systems didn't have anywhere to log errors. If things got scary,
I'd shut down and light a red LED.
Well, horses for courses. If the temperature controller is trying to
hold something just above 0 C in a subzero environment, shutting down
might be exactly the wrong answer.
And a system that can produce NaNs in the normal operation of a control >system is just plain broken--it's got serious algorithmic problems, not
so much numerical ones.
NAN wouldn't be useful. A saturating math package let me make range
checks when prudent, but not every step of every expression. No traps
to handle.
The s32.32 saturating math package was fun to write, in 68332
assembly. It was fast because it didn't need any normalizing. Well,
divide was a nuisance.
Integer in/out conversions were fast. As in zero.
Sure thing, but correctness is more important than efficiency.
On Mon, 2 May 2022 09:05:37 -0700 (PDT), Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:0 make sense?
mandag den 2. maj 2022 kl. 17.54.53 UTC+2 skrev Joe Gwinn:
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=
Umm. Testing for zero doesn't necessarily change anything.
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).
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.
sorta like: <https://en.wikipedia.org/wiki/Battleshort>
Yes, same kind of thinking.
With software taking the world over battleshort is often an operating
mode, not necessarily a bit of hardware.
On Tue, 3 May 2022 10:05:26 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:0 make sense?
John Larkin wrote:
On Mon, 2 May 2022 16:52:35 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:
jlarkin@highlandsniptechnology.com wrote:
On Sun, 1 May 2022 20:27:33 -0700 (PDT), whit3rd <whit3rd@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=
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?
Log it, skip the update, and press on to the next measurement.
Fine as long as I don't fry a few hundred kilobucks of gear.
These systems didn't have anywhere to log errors. If things got scary,
I'd shut down and light a red LED.
Well, horses for courses. If the temperature controller is trying to
hold something just above 0 C in a subzero environment, shutting down
might be exactly the wrong answer.
And a system that can produce NaNs in the normal operation of a control
system is just plain broken--it's got serious algorithmic problems, not
so much numerical ones.
Ergo, a math package that doesn't make NANs, doesn't trap, doesn't
crash.
NAN wouldn't be useful. A saturating math package let me make range
checks when prudent, but not every step of every expression. No traps
to handle.
The s32.32 saturating math package was fun to write, in 68332
assembly. It was fast because it didn't need any normalizing. Well,
divide was a nuisance.
Integer in/out conversions were fast. As in zero.
Sure thing, but correctness is more important than efficiency.
My control code checked the things that really matter.
After the PWM mosfet, to the heater, there was a relay driven by a
one-shot.
The O***** I********** controller would fry NMR probes. Ours never
did.
On Tue, 3 May 2022 10:05:26 -0400, Phil Hobbs <pcdhSpamM...@electrooptical.net> wrote:0=0 make sense?
John Larkin wrote:
On Mon, 2 May 2022 16:52:35 -0400, Phil Hobbs
<pcdhSpamM...@electrooptical.net> wrote:
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/
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?
Log it, skip the update, and press on to the next measurement.
Fine as long as I don't fry a few hundred kilobucks of gear.
These systems didn't have anywhere to log errors. If things got scary,
I'd shut down and light a red LED.
Well, horses for courses. If the temperature controller is trying to
hold something just above 0 C in a subzero environment, shutting down >might be exactly the wrong answer.
And a system that can produce NaNs in the normal operation of a control >system is just plain broken--it's got serious algorithmic problems, notErgo, a math package that doesn't make NANs, doesn't trap, doesn't
so much numerical ones.
crash.
jlarkin@highlandsniptechnology.com wrote:0=0 make sense?
On Tue, 3 May 2022 10:05:26 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:
John Larkin wrote:
On Mon, 2 May 2022 16:52:35 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:
jlarkin@highlandsniptechnology.com wrote:
On Sun, 1 May 2022 20:27:33 -0700 (PDT), whit3rd <whit3rd@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/
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?
Log it, skip the update, and press on to the next measurement.
Fine as long as I don't fry a few hundred kilobucks of gear.
These systems didn't have anywhere to log errors. If things got scary, >>>> I'd shut down and light a red LED.
Well, horses for courses. If the temperature controller is trying to
hold something just above 0 C in a subzero environment, shutting down
might be exactly the wrong answer.
And a system that can produce NaNs in the normal operation of a control
system is just plain broken--it's got serious algorithmic problems, not
so much numerical ones.
Ergo, a math package that doesn't make NANs, doesn't trap, doesn't
crash.
No, a temperature control algorithm that can be proved not to lead to >singularities. In some cases it can be as simple as
(small difference)
update = ------------------------------------
sgn(denom) * (epsilon + fabs(denom))
NAN wouldn't be useful. A saturating math package let me make range
checks when prudent, but not every step of every expression. No traps
to handle.
The s32.32 saturating math package was fun to write, in 68332
assembly. It was fast because it didn't need any normalizing. Well,
divide was a nuisance.
Integer in/out conversions were fast. As in zero.
Sure thing, but correctness is more important than efficiency.
My control code checked the things that really matter.
Sure, I'm not looking at your control system design.
After the PWM mosfet, to the heater, there was a relay driven by a
one-shot.
The O***** I********** controller would fry NMR probes. Ours never
did.
I believe that, but it wasn't on account of the NaN-handling strategy. ;)
Cheers
Phil Hobbs
On Monday, May 2, 2022 at 5:01:46 PM UTC-7, John Larkin wrote:
On Mon, 02 May 2022 18:23:38 -0400, legg <le...@nospam.magma.ca> wrote:
On Sun, 01 May 2022 07:29:30 -0700, jla...@highlandsniptechnology.com
wrote:
On Sat, 30 Apr 2022 16:24:03 -0400, legg <le...@nospam.magma.ca> wrote:
I would have expected 0/0=1 ie no rational difference.
0 is the safest heater power.
Is that possible, if it's ON ?
If we have a broken thermocouple, or some cable disconnected, or a
shorted mosfet, we want to kill heater power.
That comment belongs embedded in the code that handles NAN
for the particular case where it indicates a broken thermocouple.
Otherwise it's a write-only bit of a program, and hazard in future.
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.
mandag den 2. maj 2022 kl. 22.52.48 UTC+2 skrev Phil Hobbs:make sense?
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
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?
Log it, skip the update, and press on to the next measurement.
hoping that that doesn't slow the system down to much
On Mon, 2 May 2022 15:28:46 +0100, Martin Brownmake sense?
<'''newspam'''@nonad.co.uk> wrote:
On 02/05/2022 15:10, jlarkin@highlandsniptechnology.com wrote:
On Sun, 1 May 2022 20:27:33 -0700 (PDT), whit3rd <whit3rd@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
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.
On 02/05/2022 22:02, Lasse Langwadt Christensen wrote:0 make sense?
mandag den 2. maj 2022 kl. 22.52.48 UTC+2 skrev Phil Hobbs:
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=
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?
It should worry about the skill of the programmer who wrote the code.
Log it, skip the update, and press on to the next measurement.
+1
Or maybe just count it.
Not doing the divide saves enough time to do
something else that is *directly* under the programmers control.
Divides particularly and sometimes multiplies have the possibility of >overflow or underflow if their inputs are unfriendly.
On 02/05/2022 16:54, Joe Gwinn wrote:0 make sense?
On Mon, 2 May 2022 15:28:46 +0100, Martin Brown
<'''newspam'''@nonad.co.uk> wrote:
On 02/05/2022 15:10, jlarkin@highlandsniptechnology.com wrote:
On Sun, 1 May 2022 20:27:33 -0700 (PDT), whit3rd <whit3rd@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=
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.
Yes it does. If you know you are about to divide by zero you can do
something else instead and still save time. Divides are remarkably slow. >(even today that still holds true)
I'm presently working on an algorithm that minimises divides to obtain
higher speed - at least that was the original aim. Serendipitously I
also found that then new schema simultaneously made the whole thing >considerably more accurate as well as faster.
Basically I can sometimes trade a hardware divide for a much more
horrible algebraic expression involving the other fast primitive
operations and still come out ahead on execution time and accuracy.
On Wed, 4 May 2022 09:15:20 +0100, Martin Brown0=0 make sense?
<'''newspam'''@nonad.co.uk> wrote:
On 02/05/2022 22:02, Lasse Langwadt Christensen wrote:
mandag den 2. maj 2022 kl. 22.52.48 UTC+2 skrev Phil Hobbs:
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/
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?
It should worry about the skill of the programmer who wrote the code.
Log it, skip the update, and press on to the next measurement.
+1No, count the number of superconductive magnets that were damaged. The
Or maybe just count it.
big ones had a spiral staircase to let users get to the top.
Not doing the divide saves enough time to do
something else that is *directly* under the programmers control.
Divides particularly and sometimes multiplies have the possibility of >overflow or underflow if their inputs are unfriendly.Or use a saturating math package.
Division even on the current crop of fast processors is already so slow
that explicitly defending against division by zero and the resulting
trap handling recovery is invariably faster than the alternative.
Many times you can prove that the divisor will not ever be zero but if
you can't then you should decide exactly how to handle that exception.
Division is roughly an order of magnitude slower than any of the other primitive operations on today's CPU's - it was even worse in the past.
+,-,* now execute in a single cycle and in combination with branch
prediction and speculative execution can appear to execute in fractions
of a cycle provided that the data they need is available quickly enough.
On Wednesday, 4 May 2022 at 14:31:37 UTC+1, jla...@highlandsniptechnology.com wrote:0=0 make sense?
On Wed, 4 May 2022 09:15:20 +0100, Martin Brown
<'''newspam'''@nonad.co.uk> wrote:
On 02/05/2022 22:02, Lasse Langwadt Christensen wrote:
mandag den 2. maj 2022 kl. 22.52.48 UTC+2 skrev Phil Hobbs:
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/
No, count the number of superconductive magnets that were damaged. The
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?
It should worry about the skill of the programmer who wrote the code.
Log it, skip the update, and press on to the next measurement.
+1
Or maybe just count it.
big ones had a spiral staircase to let users get to the top.
Not doing the divide saves enough time to doOr use a saturating math package.
something else that is *directly* under the programmers control.
Divides particularly and sometimes multiplies have the possibility of
overflow or underflow if their inputs are unfriendly.
A more spectacular example of what can go wrong is the failure of
an Ariane 5 rocket: >https://web.archive.org/web/20000815230639/http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html
"On 4 June 1996, the maiden flight of the Ariane 5 launcher ended in a failure. Only about 40 seconds
after initiation of the flight sequence, at an altitude of about 3700 m, the launcher veered off
its flight path, broke up and exploded.
...
The internal SRI software exception was caused during execution of a data conversion
from 64-bit floating point to 16-bit signed integer value. The floating point number which
was converted had a value greater than what could be represented by a 16-bit signed integer.
This resulted in an Operand Error.
...
Although the source of the Operand Error has been identified, this in itself did not cause the
mission to fail. The specification of the exception-handling mechanism also contributed to
the failure. In the event of any kind of exception, the system specification stated that: the
failure should be indicated on the databus, the failure context should be stored in an EEPROM
memory (which was recovered and read out for Ariane 501), and finally, the SRI processor
should be shut down.
It was the decision to cease the processor operation which finally proved fatal."
John
On 05/04/2022 02:15 AM, Martin Brown wrote:
Division even on the current crop of fast processors is already so slow that explicitly defending against division by zero and the resulting
trap handling recovery is invariably faster than the alternative.
Many times you can prove that the divisor will not ever be zero but if
you can't then you should decide exactly how to handle that exception.
Division is roughly an order of magnitude slower than any of the other primitive operations on today's CPU's - it was even worse in the past.
+,-,* now execute in a single cycle and in combination with branch prediction and speculative execution can appear to execute in fractionshttps://www.hpmuseum.org/srw.htm
of a cycle provided that the data they need is available quickly enough.
The Fridens had no protection for a divide by zero operation despite its sophistication. It would churn away until you unplugged it. I would hope we've learned something in 70 years.
On 05/04/2022 02:15 AM, Martin Brown wrote:
Division even on the current crop of fast processors is already so slow
that explicitly defending against division by zero and the resulting
trap handling recovery is invariably faster than the alternative.
Many times you can prove that the divisor will not ever be zero but if
you can't then you should decide exactly how to handle that exception.
Division is roughly an order of magnitude slower than any of the other
primitive operations on today's CPU's - it was even worse in the past.
+,-,* now execute in a single cycle and in combination with branch
prediction and speculative execution can appear to execute in fractions
of a cycle provided that the data they need is available quickly enough.
https://www.hpmuseum.org/srw.htm
The Fridens had no protection for a divide by zero operation despite its sophistication. It would churn away until you unplugged it. I would hope we've learned something in 70 years.
rbowman wrote:
On 05/04/2022 02:15 AM, Martin Brown wrote:
Division even on the current crop of fast processors is already so slow
that explicitly defending against division by zero and the resulting
trap handling recovery is invariably faster than the alternative.
Many times you can prove that the divisor will not ever be zero but if
you can't then you should decide exactly how to handle that exception.
Division is roughly an order of magnitude slower than any of the other
primitive operations on today's CPU's - it was even worse in the past.
+,-,* now execute in a single cycle and in combination with branch
prediction and speculative execution can appear to execute in fractions
of a cycle provided that the data they need is available quickly enough.
https://www.hpmuseum.org/srw.htm
The Fridens had no protection for a divide by zero operation despite its
sophistication. It would churn away until you unplugged it. I would hope
we've learned something in 70 years.
Wow, an Italian tune-up for a desk calculator. ;)
Cheers
Phil Hobbs
On 02/05/2022 22:02, Lasse Langwadt Christensen wrote:
mandag den 2. maj 2022 kl. 22.52.48 UTC+2 skrev Phil Hobbs:
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?
It should worry about the skill of the programmer who wrote the code.
Log it, skip the update, and press on to the next measurement.
+1
Or maybe just count it. Not doing the divide saves enough time to do something else that is *directly* under the programmers control.
Divides particularly and sometimes multiplies have the possibility of overflow or underflow if their inputs are unfriendly.
hoping that that doesn't slow the system down to much
Division even on the current crop of fast processors is already so slow
that explicitly defending against division by zero and the resulting
trap handling recovery is invariably faster than the alternative.
Many times you can prove that the divisor will not ever be zero but if
you can't then you should decide exactly how to handle that exception.
Division is roughly an order of magnitude slower than any of the other primitive operations on today's CPU's - it was even worse in the past.
+,-,* now execute in a single cycle and in combination with branch
prediction and speculative execution can appear to execute in fractions
of a cycle provided that the data they need is available quickly enough.
On Wed, 4 May 2022 12:30:14 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:
rbowman wrote:
On 05/04/2022 02:15 AM, Martin Brown wrote:
Division even on the current crop of fast processors is already so slow >>>> that explicitly defending against division by zero and the resultinghttps://www.hpmuseum.org/srw.htm
trap handling recovery is invariably faster than the alternative.
Many times you can prove that the divisor will not ever be zero but if >>>> you can't then you should decide exactly how to handle that exception. >>>>
Division is roughly an order of magnitude slower than any of the other >>>> primitive operations on today's CPU's - it was even worse in the past. >>>>
+,-,* now execute in a single cycle and in combination with branch
prediction and speculative execution can appear to execute in fractions >>>> of a cycle provided that the data they need is available quickly enough. >>>
The Fridens had no protection for a divide by zero operation despite its >>> sophistication. It would churn away until you unplugged it. I would hope >>> we've learned something in 70 years.
Wow, an Italian tune-up for a desk calculator. ;)
Cheers
Phil Hobbs
I worked two summers at UNO, in a microwave spectroscopy project. I
designed hv pulsers for Stark effect spectroscopy, with big hard tubes
and thyratrons.
Two grad students spent the entire summer in a tiny room with two
Friden calculators calculating resonances. They did everything twice
and cross-checked. My PC would do that now in milliseconds.
I made 50 cents per hour and learned a lot. They could only pay
students so they gave me fake student ID number 20,000 on the theory
that they would never get that high. Some poor person is now confused
with me.
Martin Brown wrote:
Division even on the current crop of fast processors is already so slow that explicitly defending against division by zero and the resultingAnd if it's _nearly_ singular, you can get denormals, which are really
trap handling recovery is invariably faster than the alternative.
really slow.
(I expect that Lasse was thinking more about the control loop stability problem--with constant coefficients, all the pole and zero frequencies
are proportional to the update rate.)
onsdag den 4. maj 2022 kl. 16.13.11 UTC+2 skrev rbowman:
On 05/04/2022 02:15 AM, Martin Brown wrote:
Division even on the current crop of fast processors is already so slowhttps://www.hpmuseum.org/srw.htm
that explicitly defending against division by zero and the resulting
trap handling recovery is invariably faster than the alternative.
Many times you can prove that the divisor will not ever be zero but if
you can't then you should decide exactly how to handle that exception.
Division is roughly an order of magnitude slower than any of the other
primitive operations on today's CPU's - it was even worse in the past.
+,-,* now execute in a single cycle and in combination with branch
prediction and speculative execution can appear to execute in fractions
of a cycle provided that the data they need is available quickly enough.
The Fridens had no protection for a divide by zero operation despite its
sophistication. It would churn away until you unplugged it. I would hope
we've learned something in 70 years.
https://youtu.be/7Kd3R_RlXgc
On Wednesday, May 4, 2022 at 9:27:55 AM UTC-7, Phil Hobbs wrote:
Martin Brown wrote:
Division even on the current crop of fast processors is already so slowAnd if it's _nearly_ singular, you can get denormals, which are really
that explicitly defending against division by zero and the resulting
trap handling recovery is invariably faster than the alternative.
really slow.
(I expect that Lasse was thinking more about the control loop stability
problem--with constant coefficients, all the pole and zero frequencies
are proportional to the update rate.)
If you care about updating frequently, and if there's an issue with division, just... don't divide. Do everything with a lookup table; memory is cheap.
Or, it's possible to take a multivariable equation into linear operation
(a matrix operation instead of special functions) and a matrix operates on very simple formulae that don't include division or allow overflow.
On 02/05/2022 16:54, Joe Gwinn wrote:0 make sense?
On Mon, 2 May 2022 15:28:46 +0100, Martin Brown
<'''newspam'''@nonad.co.uk> wrote:
On 02/05/2022 15:10, jlarkin@highlandsniptechnology.com wrote:
On Sun, 1 May 2022 20:27:33 -0700 (PDT), whit3rd <whit3rd@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=
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.
Yes it does. If you know you are about to divide by zero you can do
something else instead and still save time. Divides are remarkably slow. >(even today that still holds true).
I'm presently working on an algorithm that minimises divides to obtain
higher speed - at least that was the original aim. Serendipitously I
also found that then new schema simultaneously made the whole thing >considerably more accurate as well as faster.
Basically I can sometimes trade a hardware divide for a much more
horrible algebraic expression involving the other fast primitive
operations and still come out ahead on execution time and accuracy.
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.
The important question here is is the divide by zero a real singularity
or as seems likely a coordinate transform singularity from taking
bearings and ranges into and out of x,y,z Cartesian coordinates.
Altaz telescope mounts have exactly the same problems as gun turrets.
Limited slew rates and allowable angles. It gets singular near the
zenith since the scope cannot spin fast enough to track the sky there.
This is a weak singularity but it has to be avoided.
Observation plans were always checked in simulated operation prior to
the actual telescope run to avoid that zone.
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.
But is it a true singularity or an artefact of how you are doing the >computing? My instinct is that it is the latter or else it could only
arise so rarely that taking the next set of measurements and processing
them would get you out of the bind. I can see that there might be cases
where the matrix inversion was singular for a single instant but that
would only be true for that time slice.
There were two schools: Just provide a very large number and proceed,
praying. Stop and print out a bunch of diagnostic information.
Clearly in a combat situation you can't afford to do anything other than >reset the calculation and try again. Or if it is because you are naively >calculating a value of tan(x) then set it to >10^18 and pray. That value >being more than enough to ensure that x = pi to double precision.
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.
Every division in safety critical or mission critical code should be
checked for whether or not it can fail divide by zero and what if
anything should be done about it if it does.
Martin Brown wrote:
On 02/05/2022 22:02, Lasse Langwadt Christensen wrote:
mandag den 2. maj 2022 kl. 22.52.48 UTC+2 skrev Phil Hobbs:
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?
It should worry about the skill of the programmer who wrote the code.
Log it, skip the update, and press on to the next measurement.
+1
Or maybe just count it. Not doing the divide saves enough time to do
something else that is *directly* under the programmers control.
Divides particularly and sometimes multiplies have the possibility of
overflow or underflow if their inputs are unfriendly.
hoping that that doesn't slow the system down to much
Division even on the current crop of fast processors is already so
slow that explicitly defending against division by zero and the
resulting trap handling recovery is invariably faster than the
alternative.
And if it's _nearly_ singular, you can get denormals, which are really
really slow.
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.
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.
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.
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 Brownnot represent just exactly zero. Just as 1 is the range from 1/2 to
<'''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
1-1/2, zero is the range from -1/2 to +1/2.
zero, yes, in the limit, the result approaches zero. But if the
If the denominator is not zero, as the numerator approaches
numerator is not zero, as the denominator approaches zero, in the limit,
the result approaches infinity. So why would 0/0=0 make sense?
Umm. Testing for zero doesn't necessarily change anything.
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).
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 Brownnot represent just exactly zero. Just as 1 is the range from 1/2 to
<'''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
1-1/2, zero is the range from -1/2 to +1/2.
zero, yes, in the limit, the result approaches zero. But if the
If the denominator is not zero, as the numerator approaches
numerator is not zero, as the denominator approaches zero, in the limit, >>the result approaches infinity. So why would 0/0=0 make sense?
Umm. Testing for zero doesn't necessarily change anything.
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).
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:sense?
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,I wrote an s32.32 saturating math package for the 68K that always did
Skybuck.
what was most reasonable.
0/0 = 0I'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
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:make sense?
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,I wrote an s32.32 saturating math package for the 68K that always did what was most reasonable.
Skybuck.
0/0 = 0I'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
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 thatThat 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
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:make sense?
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,I wrote an s32.32 saturating math package for the 68K that always did what was most reasonable.
Skybuck.
0/0 = 0I'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
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 thatThat 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
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
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 135 |
Nodes: | 16 (0 / 16) |
Uptime: | 39:05:39 |
Calls: | 2,791 |
Calls today: | 3 |
Files: | 9,644 |
Messages: | 2,482,890 |