On Wed, 4 May 2022 09:49:04 +0100, Martin Brown
<'''newspam'''@nonad.co.uk> wrote:

>On 02/05/2022 16:54, 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, 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.
>
>Yes it does. If you know you are about to divide by zero you can do
>something else instead and still save time. Divides are remarkably slow.
>(even today that still holds true).

The issue is not mathematical, it's geometric. Even if one can avoid
the actual division, the fundamental problem must still be addressed.
This requires domain knowledge, not just math, to know what's best to
do.

>I'm presently working on an algorithm that minimises divides to obtain
>higher speed - at least that was the original aim. Serendipitously I
>also found that then new schema simultaneously made the whole thing
>considerably more accurate as well as faster.
>
>Basically I can sometimes trade a hardware divide for a much more
>horrible algebraic expression involving the other fast primitive
>operations and still come out ahead on execution time and accuracy.

All true; relevance unclear.

>> I have a war story here. Many decades ago, I was the software
>> architect for the mission software of a ship self defense system that
>> shoots incoming cruise missiles down, if it can. From detection at
>> the horizon to impact on ownship is maybe twenty seconds.
>>
>> One fine day, a mob of software engineers turned up, locked in
>> argument about what to do if the engageability calculation suffered a
>> divide-by-zero exception.
>
>The important question here is is the divide by zero a real singularity
>or as seems likely a coordinate transform singularity from taking
>bearings and ranges into and out of x,y,z Cartesian coordinates.
>
>Altaz telescope mounts have exactly the same problems as gun turrets.
>Limited slew rates and allowable angles. It gets singular near the
>zenith since the scope cannot spin fast enough to track the sky there.
>This is a weak singularity but it has to be avoided.

Yes, but if the actual hardware is a gimbal, the singularity is
mechanical, not just mathematical. If avoidance is possible, that's
good. But ...

>Observation plans were always checked in simulated operation prior to
>the actual telescope run to avoid that zone.

Yep.

>> This is not a coding error per se, it's a mathematical singularity in
>> the equations - some engagement geometries will hit the singularity,
>> and the embedded realtime computers of that day could not handle the
>> more complicated math needed to avoid such things fast enough to
>> matter.
>
>But is it a true singularity or an artefact of how you are doing the
>computing? My instinct is that it is the latter or else it could only
>arise so rarely that taking the next set of measurements and processing
>them would get you out of the bind. I can see that there might be cases
>where the matrix inversion was singular for a single instant but that
>would only be true for that time slice.

I do recall doing a peer review of some algorithm design requirements
some time back. There was a vector math singularity if an airplane or
missile was flying on a line through the origin of the radar's local
coordinate system. This is a phased-array radar, so no gimbals. I
don't recall what that vector math was doing, but the solution was to
punch out a finite solid angle around that line (to accommodate
numerical noise and sensor imprecision and the like), and use special
processing there.

It does not matter if this situation is rare. Nor will the next
sample be different if the target is really flying along a radial.
Which could very well be true of say an incoming guided missile, a
situation of existential importance.

In my review example, I was lucky: with fresh eyes, I could see in
the vector math that zero divisor was possible, and from that what
physical situation would cause that to happen.

But the hazard could have been buried a bit deeper. In an algorithm I
was developing, using linear algebra, I've chased my tail trying to
figure out where random errors were coming from. Turned out to be
that one of the inputs was being wrapped into 360 degrees where the
unwrapped value was needed. Inverting a matrix involves division, and
this truncation error power was sprayed everywhere, with no error
flags thrown. The specific error pattern was the key. Recasting the
math so the angle remained unwrapped solved the problem.

>> There were two schools: Just provide a very large number and proceed,
>> praying. Stop and print out a bunch of diagnostic information.
>
>Clearly in a combat situation you can't afford to do anything other than
>reset the calculation and try again. Or if it is because you are naively
>calculating a value of tan(x) then set it to >10^18 and pray. That value
>being more than enough to ensure that x = pi to double precision.

Perhaps a reset suffices, perhaps not. The key here was domain
knowledge that a big value was more likely to work than say zero. Or
how to recast the math, if necessary.

>> Hmm. So the user, an ordinary sailor operating the self-defense
>> system is in the middle of an engagement with an incoming cruise
>> missile, and is suddenly handed a bunch or error messages, with less
>> than twenty seconds to live ... Really??? No! Just silently return
>> the best answer possible given the situation and press on, praying.
>
>Every division in safety critical or mission critical code should be
>checked for whether or not it can fail divide by zero and what if
>anything should be done about it if it does.

Yes, but the point is broader, that one should consider all corner
cases and singularities, not just divide by zero. The hard part being
to think of them all, in advance.

Joe Gwinn

On 04/05/2022 17:27, Phil Hobbs wrote:
> Martin Brown wrote:
>> On 02/05/2022 22:02, Lasse Langwadt Christensen wrote:
>>> mandag den 2. maj 2022 kl. 22.52.48 UTC+2 skrev Phil Hobbs:
>>>> jla...@highlandsniptechnology.com wrote:
>>>>> On Sun, 1 May 2022 20:27:33 -0700 (PDT), whit3rd <whi...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> On Saturday, April 30, 2022 at 1:23:21 PM UTC-7, legg wrote:
>>>>>>> On Sat, 30 Apr 2022 10:47:30 -0700 (PDT), Ricky
>>>>>>> <gnuarm.del...@gmail.com> wrote:
>>>>>>>
>>>>>>>> On Saturday, April 30, 2022 at 12:11:41 PM UTC-4,
>>>>>>>> jla...@highlandsniptechnology.com wrote:
>>>>>>
>>>>>>>>> I wrote an s32.32 saturating math package for the 68K that
>>>>>>>>> always did
>>>>>>>>> what was most reasonable.
>>>>>>>>>
>>>>>>>>> 0/0 = 0
>>>>>>>>
>>>>>>>> I'm sure no one can explain why 0/0 = 0 makes sense. Zero does
>>>>>>>> not represent just exactly zero. Just as 1 is the range from 1/2
>>>>>>>> to 1-1/2, zero is the range from -1/2 to +1/2.
>>>>>>>>
>>>>>>>> If the denominator is not zero, as the numerator approaches
>>>>>>>> zero, yes, in the limit, the result approaches zero. But if the
>>>>>>>> numerator is not zero, as the denominator approaches zero, in
>>>>>>>> the limit, the result approaches infinity. So why would 0/0=0
>>>>>>>> make sense?
>>>>>>
>>>>>>> I would have expected 0/0=1 ie no rational difference.
>>>>>>
>>>>>> That's the case if you consider lim x/x as x approaches zero. But,
>>>>>> what of the limit of 2x/x, or -x/x, as x approaches zero? NAN is the
>>>>>> best way to get a thinking human to understanding what the computer
>>>>>> is trying to express.
>>>>>
>>>>> What does a control system do when the heater voltage is computed to
>>>>> be NAN?
>>
>> It should worry about the skill of the programmer who wrote the code.
>>
>>>> Log it, skip the update, and press on to the next measurement.
>>
>> +1
>> Or maybe just count it. Not doing the divide saves enough time to do
>> something else that is *directly* under the programmers control.
>>
>> Divides particularly and sometimes multiplies have the possibility of
>> overflow or underflow if their inputs are unfriendly.
>>
>>> hoping that that doesn't slow the system down to much
>>
>> Division even on the current crop of fast processors is already so
>> slow that explicitly defending against division by zero and the
>> resulting trap handling recovery is invariably faster than the
>> alternative.
>
> And if it's _nearly_ singular, you can get denormals, which are really
> really slow.

Tell me about it! My first job as a graduate student was to sort out
some FLIC code that was running incredibly slowly written by a brilliant
physicist but in very unfriendly units. Scaled to hbar^3/c^2 it was
always teetering on the brink of denorms every step of the way.

It spent ~90% of its time in the Fortran denorm error handling code.

I had two solutions redefine hbar^3/c^2 == 1 or mask off denormal
interrupts so that they at least ran at full (slow) hardware speed.
Denormals are a favour granted to us by hardware engineers that makes
very small numbers marginally safer than very big ones.

The users (physicists) decided they wanted the latter solution.

They were very pleased with the 10x speed up.

--
Regards,
Martin Brown

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

Approximately my thoughts. Incoming missiles is a geometric problem.
Dividing by zero comes about by applying goniometric formulae,
instead of using matrix algebra that doesn't have weird exceptions.
My bet is on incompetent software engineers.

>
>--
>Rick C.

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

On Mon, 30 May 2022 12:19:27 +0200, albert@cherry.(none) (albert)
wrote:

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

Not exactly.. See earlier answers.

Joe Gwinn

On Saturday, April 30, 2022 at 1:47:35 PM UTC-4, Ricky wrote:
> On Saturday, April 30, 2022 at 12:11:41 PM UTC-4, jla...@highlandsniptechnology.com wrote:
> > On Sat, 30 Apr 2022 08:31:47 -0700 (PDT), Skybuck Flying
> > <skybuc...@gmail.com> wrote:
> >
> > >When exception masks are all enabled to stop the processor from throwing floating point exceptions the following calculation produces a somewhat strange result:
> > >
> > >0.0 / 0.0 = -nan
> > >
> > >(At least in Delphi).
> > >
> > >For now I will assume this is the case in C/C++ as well and with that I mean on x86/x64 which should and seems to be following IEEE 754 floating-point format.
> > >
> > >I am a little bit surprised by this and I want/need to know more. Where is this defined that 0.0 / 0.0 should be -NAN ?!?
> > >
> > >Problem is with the code, example:
> > >
> > >T := 0;
> > >D := 0.0 / 0.0;
> > >P := T * D;
> > >
> > >This screws up P. instead of P being zero, P is now also -NAN ?!?
> > >
> > >I find this very strange but ok.
> > >
> > >I guess a simple solution could be to set D to 0 explicitly for this case, is there perhaps another solution ? Maybe some kind of mask or rounding mode so that additional branch is not necessary ???
> > >
> > >Bye for now,
> > >Skybuck.
> > I wrote an s32.32 saturating math package for the 68K that always did
> > what was most reasonable.
> >
> > 0/0 = 0
> I'm sure no one can explain why 0/0 = 0 makes sense. Zero does not represent just exactly zero. Just as 1 is the range from 1/2 to 1-1/2, zero is the range from -1/2 to +1/2.
>
> If the denominator is not zero, as the numerator approaches zero, yes, in the limit, the result approaches zero. But if the numerator is not zero, as the denominator approaches zero, in the limit, the result approaches infinity. So why would 0/0=0 make sense?
>
> That is exactly why anything divided by zero is NAN in a good math package. If you want to produce a result for 0/0, then that should be hard coded with clear documentation of what is being done and why it is acceptable.
>
> The rationale that, "it works" means it works for the cases tested. Very sloppy indeed.

I encountered an issue where code divides by zero. In my test fixture four measurements are taken with one as a reference. The other three are converted to dB against the reference. There are hardware failures where all four measurements are zero and the three calculations produce NAN. The crosstalk test does not report a failure. Turns out the comparison operator F< returns a FALSE (not an error) when either of the inputs are NAN. So I reversed the operands and inverted the resulting flag so that now the default FALSE is a TRUE flagging an error.

Is there a convention, or is it part of the IEEE standard how NAN is handled in such comparisons?

--

Rick C.

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

mandag den 30. maj 2022 kl. 18.04.57 UTC+2 skrev Ricky:
> On Saturday, April 30, 2022 at 1:47:35 PM UTC-4, Ricky wrote:
> > On Saturday, April 30, 2022 at 12:11:41 PM UTC-4, jla...@highlandsniptechnology.com wrote:
> > > On Sat, 30 Apr 2022 08:31:47 -0700 (PDT), Skybuck Flying
> > > <skybuc...@gmail.com> wrote:
> > >
> > > >When exception masks are all enabled to stop the processor from throwing floating point exceptions the following calculation produces a somewhat strange result:
> > > >
> > > >0.0 / 0.0 = -nan
> > > >
> > > >(At least in Delphi).
> > > >
> > > >For now I will assume this is the case in C/C++ as well and with that I mean on x86/x64 which should and seems to be following IEEE 754 floating-point format.
> > > >
> > > >I am a little bit surprised by this and I want/need to know more. Where is this defined that 0.0 / 0.0 should be -NAN ?!?
> > > >
> > > >Problem is with the code, example:
> > > >
> > > >T := 0;
> > > >D := 0.0 / 0.0;
> > > >P := T * D;
> > > >
> > > >This screws up P. instead of P being zero, P is now also -NAN ?!?
> > > >
> > > >I find this very strange but ok.
> > > >
> > > >I guess a simple solution could be to set D to 0 explicitly for this case, is there perhaps another solution ? Maybe some kind of mask or rounding mode so that additional branch is not necessary ???
> > > >
> > > >Bye for now,
> > > >Skybuck.
> > > I wrote an s32.32 saturating math package for the 68K that always did
> > > what was most reasonable.
> > >
> > > 0/0 = 0
> > I'm sure no one can explain why 0/0 = 0 makes sense. Zero does not represent just exactly zero. Just as 1 is the range from 1/2 to 1-1/2, zero is the range from -1/2 to +1/2.
> >
> > If the denominator is not zero, as the numerator approaches zero, yes, in the limit, the result approaches zero. But if the numerator is not zero, as the denominator approaches zero, in the limit, the result approaches infinity. So why would 0/0=0 make sense?
> >
> > That is exactly why anything divided by zero is NAN in a good math package. If you want to produce a result for 0/0, then that should be hard coded with clear documentation of what is being done and why it is acceptable.
> >
> > The rationale that, "it works" means it works for the cases tested. Very sloppy indeed.
>
> I encountered an issue where code divides by zero. In my test fixture four measurements are taken with one as a reference. The other three are converted to dB against the reference. There are hardware failures where all four measurements are zero and the three calculations produce NAN. The crosstalk test does not report a failure. Turns out the comparison operator F< returns a FALSE (not an error) when either of the inputs are NAN. So I reversed the operands and inverted the resulting flag so that now the default FALSE is a TRUE flagging an error.
>
> Is there a convention, or is it part of the IEEE standard how NAN is handled in such comparisons?
>

https://en.wikipedia.org/wiki/NaN#Comparison_with_NaN

On Monday, May 30, 2022 at 1:02:24 PM UTC-4, lang...@fonz.dk wrote:
> mandag den 30. maj 2022 kl. 18.04.57 UTC+2 skrev Ricky:
> > On Saturday, April 30, 2022 at 1:47:35 PM UTC-4, Ricky wrote:
> > > On Saturday, April 30, 2022 at 12:11:41 PM UTC-4, jla...@highlandsniptechnology.com wrote:
> > > > On Sat, 30 Apr 2022 08:31:47 -0700 (PDT), Skybuck Flying
> > > > <skybuc...@gmail.com> wrote:
> > > >
> > > > >When exception masks are all enabled to stop the processor from throwing floating point exceptions the following calculation produces a somewhat strange result:
> > > > >
> > > > >0.0 / 0.0 = -nan
> > > > >
> > > > >(At least in Delphi).
> > > > >
> > > > >For now I will assume this is the case in C/C++ as well and with that I mean on x86/x64 which should and seems to be following IEEE 754 floating-point format.
> > > > >
> > > > >I am a little bit surprised by this and I want/need to know more. Where is this defined that 0.0 / 0.0 should be -NAN ?!?
> > > > >
> > > > >Problem is with the code, example:
> > > > >
> > > > >T := 0;
> > > > >D := 0.0 / 0.0;
> > > > >P := T * D;
> > > > >
> > > > >This screws up P. instead of P being zero, P is now also -NAN ?!?
> > > > >
> > > > >I find this very strange but ok.
> > > > >
> > > > >I guess a simple solution could be to set D to 0 explicitly for this case, is there perhaps another solution ? Maybe some kind of mask or rounding mode so that additional branch is not necessary ???
> > > > >
> > > > >Bye for now,
> > > > >Skybuck.
> > > > I wrote an s32.32 saturating math package for the 68K that always did
> > > > what was most reasonable.
> > > >
> > > > 0/0 = 0
> > > I'm sure no one can explain why 0/0 = 0 makes sense. Zero does not represent just exactly zero. Just as 1 is the range from 1/2 to 1-1/2, zero is the range from -1/2 to +1/2.
> > >
> > > If the denominator is not zero, as the numerator approaches zero, yes, in the limit, the result approaches zero. But if the numerator is not zero, as the denominator approaches zero, in the limit, the result approaches infinity. So why would 0/0=0 make sense?
> > >
> > > That is exactly why anything divided by zero is NAN in a good math package. If you want to produce a result for 0/0, then that should be hard coded with clear documentation of what is being done and why it is acceptable..
> > >
> > > The rationale that, "it works" means it works for the cases tested. Very sloppy indeed.
> >
> > I encountered an issue where code divides by zero. In my test fixture four measurements are taken with one as a reference. The other three are converted to dB against the reference. There are hardware failures where all four measurements are zero and the three calculations produce NAN. The crosstalk test does not report a failure. Turns out the comparison operator F< returns a FALSE (not an error) when either of the inputs are NAN. So I reversed the operands and inverted the resulting flag so that now the default FALSE is a TRUE flagging an error.
> >
> > Is there a convention, or is it part of the IEEE standard how NAN is handled in such comparisons?
> >
> https://en.wikipedia.org/wiki/NaN#Comparison_with_NaN

Yes, I'd seen that before and forgot it. Thanks.

--

Rick C.

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