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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

On Monday, May 2, 2022 at 1:04:34 PM UTC-4, John Larkin wrote:
> On Mon, 02 May 2022 11:54:32 -0400, Joe Gwinn <joeg...@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, 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.
> >
> >Joe Gwinn
> Yes. A best guess is better than an exception trap. Or a crash.

Or, you can code to handle such cases in a way that is logical, such as not dividing by zero in the first place. A "trap" is just the detection of the condition and implies nothing about how it is handled. So it is not inherently bad.

The crash is the sort of behavior that happens when the situation is ignored or handled poorly. Yeah, it's always better to not crash. That's a bit of a "Duh!"

--

Rick C.

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

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?

Log it, skip the update, and press on to the next measurement.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

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?
> Log it, skip the update, and press on to the next measurement.

hoping that that doesn't slow the system down to much

On Monday, May 2, 2022 at 5:02:22 PM UTC-4, lang...@fonz.dk 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?
> > Log it, skip the update, and press on to the next measurement.
> hoping that that doesn't slow the system down to much

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. Screw that up and you will have a system that does what you asked for, but not what you want.

Thinking 0/0 is an ok thing to approximate is not a way to design critical systems.

--

Rick C.

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

mandag den 2. maj 2022 kl. 23.26.42 UTC+2 skrev Ricky:
> On Monday, May 2, 2022 at 5:02:22 PM UTC-4, lang...@fonz.dk 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?
> > > Log it, skip the update, and press on to the next measurement.
> > hoping that that doesn't slow the system down to much
> 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. Screw that up and you will have a system that does what you asked for, but not what you want.
>
> Thinking 0/0 is an ok thing to approximate is not a way to design critical systems.

if it is the safe choice that keeps the system running with no ill effects why not?

On Sun, 01 May 2022 07:29:30 -0700, jlarkin@highlandsniptechnology.com
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:
>>>> >
>>>> >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.

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, 2 May 2022 13:41:52 -0700 (PDT), Ricky
<gnuarm.deletethisbit@gmail.com> wrote:

>On Monday, May 2, 2022 at 11:54:53 AM UTC-4, Joe Gwinn wrote:
>> On Mon, 2 May 2022 15:28:46 +0100, Martin Brown
>> <'''newspam'''@nonad.co.uk> wrote:
>> >On 02/05/2022 15:10, jla...@highlandsniptechnology.com wrote:
>> >> On Sun, 1 May 2022 20:27:33 -0700 (PDT), whit3rd <whi...@gmail.com>
>> >> wrote:
>> >>
>> >>> On Saturday, April 30, 2022 at 1:23:21 PM UTC-7, legg wrote:
>> >>>> On Sat, 30 Apr 2022 10:47:30 -0700 (PDT), Ricky
>> >>>> <gnuarm.del...@gmail.com> wrote:
>> >>>>
>> >>>>> On Saturday, April 30, 2022 at 12:11:41 PM UTC-4, jla...@highlandsniptechnology.com wrote:
>> >>>
>> >>>>>> I wrote an s32.32 saturating math package for the 68K that always did
>> >>>>>> what was most reasonable.
>> >>>>>>
>> >>>>>> 0/0 = 0
>> >>>>>
>> >>>>> I'm sure no one can explain why 0/0 = 0 makes sense. Zero does not represent just exactly zero. Just as 1 is the range from 1/2 to 1-1/2, zero is the range from -1/2 to +1/2.
>> >>>>>
>> >>>>> If the denominator is not zero, as the numerator approaches zero, yes, in the limit, the result approaches zero. But if the numerator is not zero, as the denominator approaches zero, in the limit, the result approaches infinity. So why would 0/0=0 make sense?
>> >>>
>> >>>> I would have expected 0/0=1 ie no rational difference.
>> >>>
>> >>> That's the case if you consider lim x/x as x approaches zero. But,
>> >>> what of the limit of 2x/x, or -x/x, as x approaches zero? NAN is the
>> >>> best way to get a thinking human to understanding what the computer
>> >>> is trying to express.
>> >>
>> >> What does a control system do when the heater voltage is computed to
>> >> be NAN?
>> >
>> >Shut down. The situation should never arise if you have scaled the
>> >problem correctly and you should never be dividing by zero anyway.
>> >
>> >If the denominator of a division is zero then you haven't thought out
>> >the representation of your problem correctly. Testing for zero is
>> >usually quick (and often implicitly available in integer arithmetic).
>> Umm. Testing for zero doesn't necessarily change anything.
>>
>> I have a war story here. Many decades ago, I was the software
>> architect for the mission software of a ship self defense system that
>> shoots incoming cruise missiles down, if it can. From detection at
>> the horizon to impact on ownship is maybe twenty seconds.
>>
>> One fine day, a mob of software engineers turned up, locked in
>> argument about what to do if the engageability calculation suffered a
>> divide-by-zero exception.
>>
>> This is not a coding error per se, it's a mathematical singularity in
>> the equations - some engagement geometries will hit the singularity,
>> and the embedded realtime computers of that day could not handle the
>> more complicated math needed to avoid such things fast enough to
>> matter.
>>
>> There were two schools: Just provide a very large number and proceed,
>> praying. Stop and print out a bunch of diagnostic information.
>>
>> Hmm. So the user, an ordinary sailor operating the self-defense
>> system is in the middle of an engagement with an incoming cruise
>> missile, and is suddenly handed a bunch or error messages, with less
>> than twenty seconds to live ... Really??? No! Just silently return
>> the best answer possible given the situation and press on, praying.
>
>Was this because they could not use quaternions? I've heard of 3D calculations that are problematic because of issues in the math. They solve that in 3 dimensional control by adding a forth coordinate, quaternions, but obviously more calculations.

The problem was the extremely limited computer power available then.
Later missiles do use quaternions in their autopilots for just that
reason. Quaternions have their own oddities to be managed.

Nor is it clear that quaternions would have solved a singularity in
engagement math, which is not a form of gimbal lock. I don't know
what is done these days, but I have run into essential singularities
in modern stuff.

Joe Gwinn

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=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?
>
>Log it, skip the update, and press on to the next measurement.
>
>Cheers
>
>Phil Hobbs

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.

--

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

On Mon, 02 May 2022 18:23:38 -0400, legg <legg@nospam.magma.ca> wrote:

>On Sun, 01 May 2022 07:29:30 -0700, jlarkin@highlandsniptechnology.com
>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:
>>>>> >
>>>>> >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.
>
>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.

In same cases, hundreds of rabbits died to make enough of some enzyme
to analyze. We didn't want to poach the samples. Or toast an NMR
probe.

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

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