0.0 / 0.0 = -NAN ?...

[Skybuck Flying]

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.

 

[server]

On Sat, 30 Apr 2022 08:31:47 -0700 (PDT), Skybuck Flying
<skybuckflying@gmail.com> wrote:

When exception masks are all enabled to stop the processor from throwing floating point exceptions the following calculation produces a somewhat strange result:

0.0 / 0.0 = -nan

(At least in Delphi).

For now I will assume this is the case in C/C++ as well and with that I mean on x86/x64 which should and seems to be following IEEE 754 floating-point format.

I am a little bit surprised by this and I want/need to know more. Where is this defined that 0.0 / 0.0 should be -NAN ?!?

Problem is with the code, example:

T := 0;
D := 0.0 / 0.0;
P := T * D;

This screws up P. instead of P being zero, P is now also -NAN ?!?

I find this very strange but ok.

I guess a simple solution could be to set D to 0 explicitly for this case, is there perhaps another solution ? Maybe some kind of mask or rounding mode so that additional branch is not necessary ???

Bye for now,
Skybuck.

I wrote an s32.32 saturating math package for the 68K that always did
what was most reasonable.

0/0 = 0

n/0 = saturated max

big/little = saturated max

big+big = saturated max

It ran real-world control loops sensibly without crashing.





--

Anybody can count to one.

- Robert Widlar

 

[Ricky]

On Saturday, April 30, 2022 at 12:11:41 PM UTC-4, jla...@highlandsniptechnology.com wrote:

On Sat, 30 Apr 2022 08:31:47 -0700 (PDT), Skybuck Flying
skybuc...@gmail.com> wrote:

When exception masks are all enabled to stop the processor from throwing floating point exceptions the following calculation produces a somewhat strange result:

0.0 / 0.0 = -nan

(At least in Delphi).

For now I will assume this is the case in C/C++ as well and with that I mean on x86/x64 which should and seems to be following IEEE 754 floating-point format.

I am a little bit surprised by this and I want/need to know more. Where is this defined that 0.0 / 0.0 should be -NAN ?!?

Problem is with the code, example:

T := 0;
D := 0.0 / 0.0;
P := T * D;

This screws up P. instead of P being zero, P is now also -NAN ?!?

I find this very strange but ok.

I guess a simple solution could be to set D to 0 explicitly for this case, is there perhaps another solution ? Maybe some kind of mask or rounding mode so that additional branch is not necessary ???

Bye for now,
Skybuck.
I wrote an s32.32 saturating math package for the 68K that always did
what was most reasonable.

0/0 = 0

I\'m sure no one can explain why 0/0 = 0 makes sense. Zero does not represent just exactly zero. Just as 1 is the range from 1/2 to 1-1/2, zero is the range from -1/2 to +1/2.

If the denominator is not zero, as the numerator approaches zero, yes, in the limit, the result approaches zero. But if the numerator is not zero, as the denominator approaches zero, in the limit, the result approaches infinity. So why would 0/0=0 make sense?

That is exactly why anything divided by zero is NAN in a good math package. If you want to produce a result for 0/0, then that should be hard coded with clear documentation of what is being done and why it is acceptable.

The rationale that, \"it works\" means it works for the cases tested. Very sloppy indeed.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

 

[legg]

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 ???

Bye for now,
Skybuck.
I wrote an s32.32 saturating math package for the 68K that always did
what was most reasonable.

0/0 = 0

I\'m sure no one can explain why 0/0 = 0 makes sense. Zero does not represent just exactly zero. Just as 1 is the range from 1/2 to 1-1/2, zero is the range from -1/2 to +1/2.

If the denominator is not zero, as the numerator approaches zero, yes, in the limit, the result approaches zero. But if the numerator is not zero, as the denominator approaches zero, in the limit, the result approaches infinity. So why would 0/0=0 make sense?

That is exactly why anything divided by zero is NAN in a good math package. If you want to produce a result for 0/0, then that should be hard coded with clear documentation of what is being done and why it is acceptable.

The rationale that, \"it works\" means it works for the cases tested. Very sloppy indeed.

I would have expected 0/0=1 ie no rational difference.

RL

 

[Jasen Betts]

On 2022-04-30, Skybuck Flying <skybuckflying@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.

You get nan in C see the standards documents.

> 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 ?!?

I guess this was invented by Borland, SFAIK they made all the decisions.

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 ?!?

seems reasonable to me.
--
Jasen.

 

[Martin Brown]

On 30/04/2022 21:24, legg 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:

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;

TBH I\'m surprised that this code will even compile!

Most Compilers these days will spot /0.0 a mile off at compile time.

Delphi might be sufficiently prehistoric not to. JPI M2 which underpins
it was quite a good compiler in its day but that was over 4 decades ago.

XDS M2 intended as a teaching compiler spots it but by default will
generate code that executes a hard division by zero trap at runtime. It
can be persuaded to warn on fatal errors that are detected at compile
time but the default is to let students suffer until they learn to RTFM.
It also does the same for using uninitialised variables.

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 ???

You should always code defensively so that you get exactly the behaviour
that you want with edge cases. Dividing anything by zero is never good.
(and on modern architectures the first comparison test is almost free)
Speculative execution has changed the game somewhat.

You need to know exactly how the thing goes wrong when x=+0.

0/x is a qNaN
x/x is a qNaN
1/x is +infinity

Arguably what IEEE754 FP could have permitted is

0*qNaN = 0

That is usually true. Provided that you keep 0*Inf = Inf

I wrote an s32.32 saturating math package for the 68K that always did
what was most reasonable.

0/0 = 0

That isn\'t particularly reasonable.

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.

0/0 = qNaN

Unless you know by other analytical means that it doesn\'t. eg

sinc(x) = sin(x)/x = 1 when x = 0

Is perfectly well defined analytically but not in IEEE754 FP math.

If the denominator is not zero, as the numerator approaches zero, yes, in the limit, the result approaches zero. But if the numerator is not zero, as the denominator approaches zero, in the limit, the result approaches infinity. So why would 0/0=0 make sense?

That is exactly why anything divided by zero is NAN in a good math package. If you want to produce a result for 0/0, then that should be hard coded with clear documentation of what is being done and why it is acceptable.

The rationale that, \"it works\" means it works for the cases tested. Very sloppy indeed.

I would have expected 0/0=1 ie no rational difference.

Still a bad idea although likely to work better than 0/0 = 0.

0/0 = qNaN

0*qNaN = 0

0*Inf = Inf

Incidentally I have noticed in some of my regression tests on compilers
that with even functions and all go faster stripes enabled +0.0 != -0.0

+0.0 is a true zero

But some compilers negate +0.0 to the smallest possible negative denorm.

I suspect someone at Mickeysoft doesn\'t understand twos compliment
numbers properly. It only shows up for me on a handful of test cases.

--
Regards,
Martin Brown

 

[server]

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:

0.0 / 0.0 = -nan

(At least in Delphi).

For now I will assume this is the case in C/C++ as well and with that I mean on x86/x64 which should and seems to be following IEEE 754 floating-point format.

I am a little bit surprised by this and I want/need to know more. Where is this defined that 0.0 / 0.0 should be -NAN ?!?

Problem is with the code, example:

T := 0;
D := 0.0 / 0.0;
P := T * D;

This screws up P. instead of P being zero, P is now also -NAN ?!?

I find this very strange but ok.

I guess a simple solution could be to set D to 0 explicitly for this case, is there perhaps another solution ? Maybe some kind of mask or rounding mode so that additional branch is not necessary ???

Bye for now,
Skybuck.
I wrote an s32.32 saturating math package for the 68K that always did
what was most reasonable.

0/0 = 0

I\'m sure no one can explain why 0/0 = 0 makes sense. Zero does not represent just exactly zero. Just as 1 is the range from 1/2 to 1-1/2, zero is the range from -1/2 to +1/2.

If the denominator is not zero, as the numerator approaches zero, yes, in the limit, the result approaches zero. But if the numerator is not zero, as the denominator approaches zero, in the limit, the result approaches infinity. So why would 0/0=0 make sense?

That is exactly why anything divided by zero is NAN in a good math package. If you want to produce a result for 0/0, then that should be hard coded with clear documentation of what is being done and why it is acceptable.

The rationale that, \"it works\" means it works for the cases tested. Very sloppy indeed.

I would have expected 0/0=1 ie no rational difference.

RL

0 is the safest heater power.



--

Anybody can count to one.

- Robert Widlar

 

[Skybuck Flying]

I discovered another dangerous one while trying to compute overlap of interval (basically ranges) and/or trying to clip/cap line segments:

0 * +infinity = -NAN

This happens as the ray is on the edge of a boundary/box... cause tMinX will become -NAN.

Leading to weird situations depending on how the code was written, either the wrong point will be taken or it will not clip at all.

Once intersection segment with ray and box has been calculated, the ray segment has to be checked against the interestion segment to check if it overlaps... it\'s still possible it does not overlap.. for a \"ray segment box intersection\" algorithm. Analog to \"line triangle intersection\" algorithm, first \"line plane intersection\" then check if intersection point lies inside triangle which lies inside the plane.

I have seen some papers that try and work around these issues at least for ray/box intersection, but if these tricks work for ray segment box intersection remains to be seen.

Anyway best way to solve it is to use custom code for when delta x, y, or z is zero... instead of trying to divide or multiply by zero and infinity and such things cause certain combinations can lead to -NAN problems. Also win32 and win64 behave differently in delphi somewhat... perhaps 0 * infinity produces something else in win64... not yet sure...

It\'s in my video which I will upload shortly... hmmm...

Anyway... I am leaving math hell for now... leaving fpu hell... and returning back to the surface ! =D

This guy has an interesting take on it, basically saying 0 * infinity is the inverted case as 0 / 0, same kind of problem ! =D

https://math.stackexchange.com/questions/698690/when-0-is-multiplied-with-infinity-what-is-the-result

\"
What I would say is that you can multiply any non-zero number by infinity and get either infinity or negative infinity as long as it isn\'t used in any mathematical proof. Because multiplying by infinity is the equivalent of dividing by 0. When you allow things like that in proofs you end up with nonsense like 1 = 0. Multiplying 0 by infinity is the equivalent of 0/0 which is undefined. –
PHP Guru
\"

(Here will be my video: https://youtu.be/lAcneKBJ9zY in case anybody wants to see some math hell in action lol, doubt it )

Bye,
Skybuck =D

 

[whit3rd]

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.

 

[legg]

On Sun, 1 May 2022 19:23:10 -0700 (PDT), Skybuck Flying
<skybuckflying@gmail.com> wrote:

I discovered another dangerous one while trying to compute overlap of interval (basically ranges) and/or trying to clip/cap line segments:

0 * +infinity = -NAN

This happens as the ray is on the edge of a boundary/box... cause tMinX will become -NAN.

Leading to weird situations depending on how the code was written, either the wrong point will be taken or it will not clip at all.

Once intersection segment with ray and box has been calculated, the ray segment has to be checked against the interestion segment to check if it overlaps... it\'s still possible it does not overlap.. for a \"ray segment box intersection\" algorithm. Analog to \"line triangle intersection\" algorithm, first \"line plane intersection\" then check if intersection point lies inside triangle which lies inside the plane.

I have seen some papers that try and work around these issues at least for ray/box intersection, but if these tricks work for ray segment box intersection remains to be seen.

Anyway best way to solve it is to use custom code for when delta x, y, or z is zero... instead of trying to divide or multiply by zero and infinity and such things cause certain combinations can lead to -NAN problems. Also win32 and win64 behave differently in delphi somewhat... perhaps 0 * infinity produces something else in win64... not yet sure...

It\'s in my video which I will upload shortly... hmmm...

Anyway... I am leaving math hell for now... leaving fpu hell... and returning back to the surface ! =D

This guy has an interesting take on it, basically saying 0 * infinity is the inverted case as 0 / 0, same kind of problem ! =D

https://math.stackexchange.com/questions/698690/when-0-is-multiplied-with-infinity-what-is-the-result

\"
What I would say is that you can multiply any non-zero number by infinity and get either infinity or negative infinity as long as it isn\'t used in any mathematical proof. Because multiplying by infinity is the equivalent of dividing by 0. When you allow things like that in proofs you end up with nonsense like 1 = 0. Multiplying 0 by infinity is the equivalent of 0/0 which is undefined. –
PHP Guru
\"

(Here will be my video: https://youtu.be/lAcneKBJ9zY in case anybody wants to see some math hell in action lol, doubt it )

Bye,
Skybuck =D

Two and a half hours?

You need an editor.

RL

 

[server]

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 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?



--

Anybody can count to one.

- Robert Widlar

 

[Martin Brown]

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 make sense?

I would have expected 0/0=1 ie no rational difference.

That\'s the case if you consider lim x/x as x approaches zero. But,
what of the limit of 2x/x, or -x/x, as x approaches zero? NAN is the
best way to get a thinking human to understanding what the computer
is trying to express.

What does a control system do when the heater voltage is computed to
be NAN?

Shut down. The situation should never arise if you have scaled the
problem correctly and you should never be dividing by zero anyway.

If the denominator of a division is zero then you haven\'t thought out
the representation of your problem correctly. Testing for zero is
usually quick (and often implicitly available in integer arithmetic).

--
Regards,
Martin Brown

 

[server]

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=0 make sense?

I would have expected 0/0=1 ie no rational difference.

That\'s the case if you consider lim x/x as x approaches zero. But,
what of the limit of 2x/x, or -x/x, as x approaches zero? NAN is the
best way to get a thinking human to understanding what the computer
is trying to express.

What does a control system do when the heater voltage is computed to
be NAN?

Shut down. The situation should never arise if you have scaled the
problem correctly and you should never be dividing by zero anyway.

Most ADCs can output zero. It\'s convenient to have a math package that
usually outputs a reasonable number, which reduces the number of tests
that you have to do.

My NMR temperature controllers drove the heaters PWM from rectified
unregulated DC. I measured the DC supply voltage and computed the PWM
such as to correct for line voltage fluctuations. An exception-free
math package helped.

Opamps never output NAV!

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).

--

Anybody can count to one.

- Robert Widlar

 

[Joe Gwinn]

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=0 make sense?

I would have expected 0/0=1 ie no rational difference.

That\'s the case if you consider lim x/x as x approaches zero. But,
what of the limit of 2x/x, or -x/x, as x approaches zero? NAN is the
best way to get a thinking human to understanding what the computer
is trying to express.

What does a control system do when the heater voltage is computed to
be NAN?

Shut down. The situation should never arise if you have scaled the
problem correctly and you should never be dividing by zero anyway.

If the denominator of a division is zero then you haven\'t thought out
the representation of your problem correctly. Testing for zero is
usually quick (and often implicitly available in integer arithmetic).

Umm. Testing for zero doesn\'t necessarily change anything.

I have a war story here. Many decades ago, I was the software
architect for the mission software of a ship self defense system that
shoots incoming cruise missiles down, if it can. From detection at
the horizon to impact on ownship is maybe twenty seconds.

One fine day, a mob of software engineers turned up, locked in
argument about what to do if the engageability calculation suffered a
divide-by-zero exception.

This is not a coding error per se, it\'s a mathematical singularity in
the equations - some engagement geometries will hit the singularity,
and the embedded realtime computers of that day could not handle the
more complicated math needed to avoid such things fast enough to
matter.

There were two schools: Just provide a very large number and proceed,
praying. Stop and print out a bunch of diagnostic information.

Hmm. So the user, an ordinary sailor operating the self-defense
system is in the middle of an engagement with an incoming cruise
missile, and is suddenly handed a bunch or error messages, with less
than twenty seconds to live ... Really??? No! Just silently return
the best answer possible given the situation and press on, praying.

Joe Gwinn

 

[Lasse Langwadt Christensen]

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=0 make sense?

I would have expected 0/0=1 ie no rational difference.

That\'s the case if you consider lim x/x as x approaches zero. But,
what of the limit of 2x/x, or -x/x, as x approaches zero? NAN is the
best way to get a thinking human to understanding what the computer
is trying to express.

What does a control system do when the heater voltage is computed to
be NAN?

Shut down. The situation should never arise if you have scaled the
problem correctly and you should never be dividing by zero anyway.

If the denominator of a division is zero then you haven\'t thought out
the representation of your problem correctly. Testing for zero is
usually quick (and often implicitly available in integer arithmetic).
Umm. Testing for zero doesn\'t necessarily change anything.

I have a war story here. Many decades ago, I was the software
architect for the mission software of a ship self defense system that
shoots incoming cruise missiles down, if it can. From detection at
the horizon to impact on ownship is maybe twenty seconds.

One fine day, a mob of software engineers turned up, locked in
argument about what to do if the engageability calculation suffered a
divide-by-zero exception.

This is not a coding error per se, it\'s a mathematical singularity in
the equations - some engagement geometries will hit the singularity,
and the embedded realtime computers of that day could not handle the
more complicated math needed to avoid such things fast enough to
matter.

There were two schools: Just provide a very large number and proceed,
praying. Stop and print out a bunch of diagnostic information.

Hmm. So the user, an ordinary sailor operating the self-defense
system is in the middle of an engagement with an incoming cruise
missile, and is suddenly handed a bunch or error messages, with less
than twenty seconds to live ... Really??? No! Just silently return
the best answer possible given the situation and press on, praying.

sorta like: https://en.wikipedia.org/wiki/Battleshort

 

[John Larkin]

On Mon, 02 May 2022 11:54:32 -0400, Joe Gwinn <joegwinn@comcast.net>
wrote:

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=0 make sense?

I would have expected 0/0=1 ie no rational difference.

That\'s the case if you consider lim x/x as x approaches zero. But,
what of the limit of 2x/x, or -x/x, as x approaches zero? NAN is the
best way to get a thinking human to understanding what the computer
is trying to express.

What does a control system do when the heater voltage is computed to
be NAN?

Shut down. The situation should never arise if you have scaled the
problem correctly and you should never be dividing by zero anyway.

If the denominator of a division is zero then you haven\'t thought out
the representation of your problem correctly. Testing for zero is
usually quick (and often implicitly available in integer arithmetic).

Umm. Testing for zero doesn\'t necessarily change anything.

I have a war story here. Many decades ago, I was the software
architect for the mission software of a ship self defense system that
shoots incoming cruise missiles down, if it can. From detection at
the horizon to impact on ownship is maybe twenty seconds.

One fine day, a mob of software engineers turned up, locked in
argument about what to do if the engageability calculation suffered a
divide-by-zero exception.

This is not a coding error per se, it\'s a mathematical singularity in
the equations - some engagement geometries will hit the singularity,
and the embedded realtime computers of that day could not handle the
more complicated math needed to avoid such things fast enough to
matter.

There were two schools: Just provide a very large number and proceed,
praying. Stop and print out a bunch of diagnostic information.

Hmm. So the user, an ordinary sailor operating the self-defense
system is in the middle of an engagement with an incoming cruise
missile, and is suddenly handed a bunch or error messages, with less
than twenty seconds to live ... Really??? No! Just silently return
the best answer possible given the situation and press on, praying.

Joe Gwinn

Yes. A best guess is better than an exception trap. Or a crash.

--

If a man will begin with certainties, he shall end with doubts,
but if he will be content to begin with doubts he shall end in certainties.
Francis Bacon

 

[Joe Gwinn]

On Mon, 2 May 2022 09:05:37 -0700 (PDT), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:

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=0 make sense?

I would have expected 0/0=1 ie no rational difference.

That\'s the case if you consider lim x/x as x approaches zero. But,
what of the limit of 2x/x, or -x/x, as x approaches zero? NAN is the
best way to get a thinking human to understanding what the computer
is trying to express.

What does a control system do when the heater voltage is computed to
be NAN?

Shut down. The situation should never arise if you have scaled the
problem correctly and you should never be dividing by zero anyway.

If the denominator of a division is zero then you haven\'t thought out
the representation of your problem correctly. Testing for zero is
usually quick (and often implicitly available in integer arithmetic).
Umm. Testing for zero doesn\'t necessarily change anything.

I have a war story here. Many decades ago, I was the software
architect for the mission software of a ship self defense system that
shoots incoming cruise missiles down, if it can. From detection at
the horizon to impact on ownship is maybe twenty seconds.

One fine day, a mob of software engineers turned up, locked in
argument about what to do if the engageability calculation suffered a
divide-by-zero exception.

This is not a coding error per se, it\'s a mathematical singularity in
the equations - some engagement geometries will hit the singularity,
and the embedded realtime computers of that day could not handle the
more complicated math needed to avoid such things fast enough to
matter.

There were two schools: Just provide a very large number and proceed,
praying. Stop and print out a bunch of diagnostic information.

Hmm. So the user, an ordinary sailor operating the self-defense
system is in the middle of an engagement with an incoming cruise
missile, and is suddenly handed a bunch or error messages, with less
than twenty seconds to live ... Really??? No! Just silently return
the best answer possible given the situation and press on, praying.

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.

Joe Gwinn

 

[whit3rd]

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.

 

[John Larkin]

On Mon, 2 May 2022 12:20:57 -0700 (PDT), whit3rd <whit3rd@gmail.com>
wrote:

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.

For NMR, you don\'t want to damage a $100K probe or a million dollar
magnet.

--

If a man will begin with certainties, he shall end with doubts,
but if he will be content to begin with doubts he shall end in certainties.
Francis Bacon

 

[Ricky]

On Monday, May 2, 2022 at 11:54:53 AM UTC-4, Joe Gwinn wrote:

On Mon, 2 May 2022 15:28:46 +0100, Martin Brown
\'\'\'newspam\'\'\'@nonad.co.uk> wrote:
On 02/05/2022 15:10, jla...@highlandsniptechnology.com wrote:
On Sun, 1 May 2022 20:27:33 -0700 (PDT), whit3rd <whi...@gmail.com
wrote:

On Saturday, April 30, 2022 at 1:23:21 PM UTC-7, legg wrote:
On Sat, 30 Apr 2022 10:47:30 -0700 (PDT), Ricky
gnuarm.del...@gmail.com> wrote:

On Saturday, April 30, 2022 at 12:11:41 PM UTC-4, jla...@highlandsniptechnology.com wrote:

I wrote an s32.32 saturating math package for the 68K that always did
what was most reasonable.

0/0 = 0

I\'m sure no one can explain why 0/0 = 0 makes sense. Zero does not represent just exactly zero. Just as 1 is the range from 1/2 to 1-1/2, zero is the range from -1/2 to +1/2.

If the denominator is not zero, as the numerator approaches zero, yes, in the limit, the result approaches zero. But if the numerator is not zero, as the denominator approaches zero, in the limit, the result approaches infinity. So why would 0/0=0 make sense?

I would have expected 0/0=1 ie no rational difference.

That\'s the case if you consider lim x/x as x approaches zero. But,
what of the limit of 2x/x, or -x/x, as x approaches zero? NAN is the
best way to get a thinking human to understanding what the computer
is trying to express.

What does a control system do when the heater voltage is computed to
be NAN?

Shut down. The situation should never arise if you have scaled the
problem correctly and you should never be dividing by zero anyway.

If the denominator of a division is zero then you haven\'t thought out
the representation of your problem correctly. Testing for zero is
usually quick (and often implicitly available in integer arithmetic).
Umm. Testing for zero doesn\'t necessarily change anything.

I have a war story here. Many decades ago, I was the software
architect for the mission software of a ship self defense system that
shoots incoming cruise missiles down, if it can. From detection at
the horizon to impact on ownship is maybe twenty seconds.

One fine day, a mob of software engineers turned up, locked in
argument about what to do if the engageability calculation suffered a
divide-by-zero exception.

This is not a coding error per se, it\'s a mathematical singularity in
the equations - some engagement geometries will hit the singularity,
and the embedded realtime computers of that day could not handle the
more complicated math needed to avoid such things fast enough to
matter.

There were two schools: Just provide a very large number and proceed,
praying. Stop and print out a bunch of diagnostic information.

Hmm. So the user, an ordinary sailor operating the self-defense
system is in the middle of an engagement with an incoming cruise
missile, and is suddenly handed a bunch or error messages, with less
than twenty seconds to live ... Really??? No! Just silently return
the best answer possible given the situation and press on, praying.

Was this because they could not use quaternions? I\'ve heard of 3D calculations that are problematic because of issues in the math. They solve that in 3 dimensional control by adding a forth coordinate, quaternions, but obviously more calculations.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209