• Re: 0.0 / 0.0 = -NAN ?

    From jlarkin@highlandsniptechnology.com@21:1/5 to skybuckflying@gmail.com on Sat Apr 30 09:11:27 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to jla...@highlandsniptechnology.com on Sat Apr 30 10:47:30 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From legg@21:1/5 to gnuarm.deletethisbit@gmail.com on Sat Apr 30 16:24:03 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jasen Betts@21:1/5 to Skybuck Flying on Sun May 1 03:49:25 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to legg on Sun May 1 09:35:35 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to legg on Sun May 1 07:29:30 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Skybuck Flying@21:1/5 to All on Sun May 1 19:23:10 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From whit3rd@21:1/5 to legg on Sun May 1 20:27:33 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From legg@21:1/5 to skybuckflying@gmail.com on Mon May 2 08:38:50 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to All on Mon May 2 07:10:34 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to jlarkin@highlandsniptechnology.com on Mon May 2 15:28:46 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to '''newspam'''@nonad.co.uk on Mon May 2 08:14:35 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to '''newspam'''@nonad.co.uk on Mon May 2 11:54:32 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Mon May 2 09:05:37 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to All on Mon May 2 10:04:21 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to langwadt@fonz.dk on Mon May 2 13:06:57 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From whit3rd@21:1/5 to jla...@highlandsniptechnology.com on Mon May 2 12:20:57 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to All on Mon May 2 12:53:47 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to Joe Gwinn on Mon May 2 13:41:52 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to John Larkin on Mon May 2 13:42:12 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Mon May 2 14:02:17 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to jlarkin@highlandsniptechnology.com on Mon May 2 16:52:35 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to lang...@fonz.dk on Mon May 2 14:26:38 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Mon May 2 14:30:24 2022
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From legg@21:1/5 to All on Mon May 2 18:23:38 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to gnuarm.deletethisbit@gmail.com on Mon May 2 19:14:29 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Mon May 2 16:34:38 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to legg on Mon May 2 17:01:35 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From whit3rd@21:1/5 to John Larkin on Mon May 2 18:48:38 2022
    On Monday, May 2, 2022 at 5:01:46 PM UTC-7, John Larkin wrote:
    On Mon, 02 May 2022 18:23:38 -0400, legg <le...@nospam.magma.ca> wrote:

    On Sun, 01 May 2022 07:29:30 -0700, jla...@highlandsniptechnology.com >wrote:

    On Sat, 30 Apr 2022 16:24:03 -0400, legg <le...@nospam.magma.ca> wrote:

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

    0 is the safest heater power.

    Is that possible, if it's ON ?

    If we have a broken thermocouple, or some cable disconnected, or a
    shorted mosfet, we want to kill heater power.

    That comment belongs embedded in the code that handles NAN
    for the particular case where it indicates a broken thermocouple.
    Otherwise it's a write-only bit of a program, and hazard in future.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to All on Mon May 2 19:20:41 2022
    On Monday, May 2, 2022 at 9:48:42 PM UTC-4, whit3rd wrote:
    On Monday, May 2, 2022 at 5:01:46 PM UTC-7, John Larkin wrote:
    On Mon, 02 May 2022 18:23:38 -0400, legg <le...@nospam.magma.ca> wrote:

    On Sun, 01 May 2022 07:29:30 -0700, jla...@highlandsniptechnology.com >wrote:

    On Sat, 30 Apr 2022 16:24:03 -0400, legg <le...@nospam.magma.ca> wrote:

    I would have expected 0/0=1 ie no rational difference.
    0 is the safest heater power.

    Is that possible, if it's ON ?

    If we have a broken thermocouple, or some cable disconnected, or a
    shorted mosfet, we want to kill heater power.
    That comment belongs embedded in the code that handles NAN
    for the particular case where it indicates a broken thermocouple.
    Otherwise it's a write-only bit of a program, and hazard in future.

    1+

    It's no different from a trap, really, except there is no opportunity to do anything unique given the code that is doing the calculation. It works the same in all uses, which, obviously may or may not be appropriate. In other words, very sloppy and
    hard to maintain.

    --

    Rick C.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to Lasse Langwadt Christensen on Tue May 3 10:01:11 2022
    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?
    Log it, skip the update, and press on to the next measurement.

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


    Well, if the error and the slope are both zero, it doesn't matter if the
    update occurs or not.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to John Larkin on Tue May 3 10:05:26 2022
    John Larkin wrote:
    On Mon, 2 May 2022 16:52:35 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    jlarkin@highlandsniptechnology.com wrote:
    On Sun, 1 May 2022 20:27:33 -0700 (PDT), whit3rd <whit3rd@gmail.com>
    wrote:

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

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

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

    0/0 = 0

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

    If the denominator is not zero, as the numerator approaches zero, yes, in the limit, the result approaches zero. But if the numerator is not zero, as the denominator approaches zero, in the limit, the result approaches infinity. So why would 0/0=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.


    Fine as long as I don't fry a few hundred kilobucks of gear.

    These systems didn't have anywhere to log errors. If things got scary,
    I'd shut down and light a red LED.

    Well, horses for courses. If the temperature controller is trying to
    hold something just above 0 C in a subzero environment, shutting down
    might be exactly the wrong answer.

    And a system that can produce NaNs in the normal operation of a control
    system is just plain broken--it's got serious algorithmic problems, not
    so much numerical ones.

    NAN wouldn't be useful. A saturating math package let me make range
    checks when prudent, but not every step of every expression. No traps
    to handle.

    The s32.32 saturating math package was fun to write, in 68332
    assembly. It was fast because it didn't need any normalizing. Well,
    divide was a nuisance.

    Integer in/out conversions were fast. As in zero.

    Sure thing, but correctness is more important than efficiency.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Tue May 3 07:26:49 2022
    On Tue, 3 May 2022 10:05:26 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    John Larkin wrote:
    On Mon, 2 May 2022 16:52:35 -0400, Phil Hobbs
    <pcdhSpamMeSenseless@electrooptical.net> wrote:

    jlarkin@highlandsniptechnology.com wrote:
    On Sun, 1 May 2022 20:27:33 -0700 (PDT), whit3rd <whit3rd@gmail.com>
    wrote:

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

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

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

    0/0 = 0

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

    If the denominator is not zero, as the numerator approaches zero, yes, in the limit, the result approaches zero. But if the numerator is not zero, as the denominator approaches zero, in the limit, the result approaches infinity. So why would 0/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.


    Fine as long as I don't fry a few hundred kilobucks of gear.

    These systems didn't have anywhere to log errors. If things got scary,
    I'd shut down and light a red LED.

    Well, horses for courses. If the temperature controller is trying to
    hold something just above 0 C in a subzero environment, shutting down
    might be exactly the wrong answer.

    And a system that can produce NaNs in the normal operation of a control >system is just plain broken--it's got serious algorithmic problems, not
    so much numerical ones.

    Ergo, a math package that doesn't make NANs, doesn't trap, doesn't
    crash.




    NAN wouldn't be useful. A saturating math package let me make range
    checks when prudent, but not every step of every expression. No traps
    to handle.

    The s32.32 saturating math package was fun to write, in 68332
    assembly. It was fast because it didn't need any normalizing. Well,
    divide was a nuisance.

    Integer in/out conversions were fast. As in zero.

    Sure thing, but correctness is more important than efficiency.

    My control code checked the things that really matter.

    After the PWM mosfet, to the heater, there was a relay driven by a
    one-shot.

    The O***** I********** controller would fry NMR probes. Ours never
    did.



    --

    Anybody can count to one.

    - Robert Widlar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to Joe Gwinn on Tue May 3 10:28:14 2022
    Joe Gwinn wrote:
    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.

    So that's where Douglas Adams got the idea!

    https://hitchhikers.fandom.com/wiki/Vl'Hurgs

    Cheers

    Phil Hobbs

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to jlarkin@highlandsniptechnology.com on Tue May 3 10:37:49 2022
    jlarkin@highlandsniptechnology.com wrote:
    On Tue, 3 May 2022 10:05:26 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    John Larkin wrote:
    On Mon, 2 May 2022 16:52:35 -0400, Phil Hobbs
    <pcdhSpamMeSenseless@electrooptical.net> wrote:

    jlarkin@highlandsniptechnology.com wrote:
    On Sun, 1 May 2022 20:27:33 -0700 (PDT), whit3rd <whit3rd@gmail.com> >>>>> wrote:

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

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

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

    0/0 = 0

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

    If the denominator is not zero, as the numerator approaches zero, yes, in the limit, the result approaches zero. But if the numerator is not zero, as the denominator approaches zero, in the limit, the result approaches infinity. So why would 0/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.


    Fine as long as I don't fry a few hundred kilobucks of gear.

    These systems didn't have anywhere to log errors. If things got scary,
    I'd shut down and light a red LED.

    Well, horses for courses. If the temperature controller is trying to
    hold something just above 0 C in a subzero environment, shutting down
    might be exactly the wrong answer.

    And a system that can produce NaNs in the normal operation of a control
    system is just plain broken--it's got serious algorithmic problems, not
    so much numerical ones.

    Ergo, a math package that doesn't make NANs, doesn't trap, doesn't
    crash.

    No, a temperature control algorithm that can be proved not to lead to singularities. In some cases it can be as simple as

    (small difference)
    update = ------------------------------------
    sgn(denom) * (epsilon + fabs(denom))





    NAN wouldn't be useful. A saturating math package let me make range
    checks when prudent, but not every step of every expression. No traps
    to handle.

    The s32.32 saturating math package was fun to write, in 68332
    assembly. It was fast because it didn't need any normalizing. Well,
    divide was a nuisance.

    Integer in/out conversions were fast. As in zero.

    Sure thing, but correctness is more important than efficiency.

    My control code checked the things that really matter.

    Sure, I'm not looking at your control system design.

    After the PWM mosfet, to the heater, there was a relay driven by a
    one-shot.

    The O***** I********** controller would fry NMR probes. Ours never
    did.

    I believe that, but it wasn't on account of the NaN-handling strategy. ;)

    Cheers

    Phil Hobbs

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to jla...@highlandsniptechnology.com on Tue May 3 08:28:51 2022
    On Tuesday, May 3, 2022 at 10:27:03 AM UTC-4, jla...@highlandsniptechnology.com wrote:
    On Tue, 3 May 2022 10:05:26 -0400, Phil Hobbs <pcdhSpamM...@electrooptical.net> wrote:

    John Larkin wrote:
    On Mon, 2 May 2022 16:52:35 -0400, Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    jla...@highlandsniptechnology.com wrote:
    On Sun, 1 May 2022 20:27:33 -0700 (PDT), whit3rd <whi...@gmail.com> >>>> wrote:

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

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

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

    0/0 = 0

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

    If the denominator is not zero, as the numerator approaches zero, yes, in the limit, the result approaches zero. But if the numerator is not zero, as the denominator approaches zero, in the limit, the result approaches infinity. So why would 0/
    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.


    Fine as long as I don't fry a few hundred kilobucks of gear.

    These systems didn't have anywhere to log errors. If things got scary,
    I'd shut down and light a red LED.

    Well, horses for courses. If the temperature controller is trying to
    hold something just above 0 C in a subzero environment, shutting down >might be exactly the wrong answer.

    And a system that can produce NaNs in the normal operation of a control >system is just plain broken--it's got serious algorithmic problems, not
    so much numerical ones.
    Ergo, a math package that doesn't make NANs, doesn't trap, doesn't
    crash.

    How is reporting an invalid answer not a "crash"? Oh, it's just an error... that can lead to a crash depending on the skill level of the pilots to recognize and override the system.

    Yeah, maybe an inconsequential heater would do fine. This is not a general solution to the math issues in a system.

    What Hobbs is talking about if designing the algorithm so the NAN never happens in the first place. That also works and works for every type of system.

    --

    Rick C.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Tue May 3 08:18:17 2022
    On Tue, 3 May 2022 10:37:49 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    jlarkin@highlandsniptechnology.com wrote:
    On Tue, 3 May 2022 10:05:26 -0400, Phil Hobbs
    <pcdhSpamMeSenseless@electrooptical.net> wrote:

    John Larkin wrote:
    On Mon, 2 May 2022 16:52:35 -0400, Phil Hobbs
    <pcdhSpamMeSenseless@electrooptical.net> wrote:

    jlarkin@highlandsniptechnology.com wrote:
    On Sun, 1 May 2022 20:27:33 -0700 (PDT), whit3rd <whit3rd@gmail.com> >>>>>> wrote:

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

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

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

    0/0 = 0

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

    If the denominator is not zero, as the numerator approaches zero, yes, in the limit, the result approaches zero. But if the numerator is not zero, as the denominator approaches zero, in the limit, the result approaches infinity. So why would 0/
    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.


    Fine as long as I don't fry a few hundred kilobucks of gear.

    These systems didn't have anywhere to log errors. If things got scary, >>>> I'd shut down and light a red LED.

    Well, horses for courses. If the temperature controller is trying to
    hold something just above 0 C in a subzero environment, shutting down
    might be exactly the wrong answer.

    And a system that can produce NaNs in the normal operation of a control
    system is just plain broken--it's got serious algorithmic problems, not
    so much numerical ones.

    Ergo, a math package that doesn't make NANs, doesn't trap, doesn't
    crash.

    No, a temperature control algorithm that can be proved not to lead to >singularities. In some cases it can be as simple as

    (small difference)
    update = ------------------------------------
    sgn(denom) * (epsilon + fabs(denom))





    NAN wouldn't be useful. A saturating math package let me make range
    checks when prudent, but not every step of every expression. No traps
    to handle.

    The s32.32 saturating math package was fun to write, in 68332
    assembly. It was fast because it didn't need any normalizing. Well,
    divide was a nuisance.

    Integer in/out conversions were fast. As in zero.

    Sure thing, but correctness is more important than efficiency.

    My control code checked the things that really matter.

    Sure, I'm not looking at your control system design.

    Well, my concern was physical reality, not mathematical elegance.
    Checking for NAN after every math operation would be a nuisance. As
    would writing a trap handler.


    After the PWM mosfet, to the heater, there was a relay driven by a
    one-shot.

    The O***** I********** controller would fry NMR probes. Ours never
    did.

    I believe that, but it wasn't on account of the NaN-handling strategy. ;)

    Part of the problem was absurd EMI sensitivity... in an NMR system! I
    could shut one down from across the room with an old GR RF sig gen.
    The controller had some very sharp, very sensitive resonances around
    the thermocouple input.

    But software bugs too.

    We did things like this:

    https://www.dropbox.com/s/noapeoyk10iayoz/Chimera_Ref_Junction.JPG?raw=1


    Cheers

    Phil Hobbs


    --

    Anybody can count to one.

    - Robert Widlar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to All on Tue May 3 09:49:02 2022
    On Mon, 2 May 2022 18:48:38 -0700 (PDT), whit3rd <whit3rd@gmail.com>
    wrote:

    On Monday, May 2, 2022 at 5:01:46 PM UTC-7, John Larkin wrote:
    On Mon, 02 May 2022 18:23:38 -0400, legg <le...@nospam.magma.ca> wrote:

    On Sun, 01 May 2022 07:29:30 -0700, jla...@highlandsniptechnology.com
    wrote:

    On Sat, 30 Apr 2022 16:24:03 -0400, legg <le...@nospam.magma.ca> wrote:

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

    0 is the safest heater power.

    Is that possible, if it's ON ?

    If we have a broken thermocouple, or some cable disconnected, or a
    shorted mosfet, we want to kill heater power.

    That comment belongs embedded in the code that handles NAN
    for the particular case where it indicates a broken thermocouple.
    Otherwise it's a write-only bit of a program, and hazard in future.

    My code is well commented. The saturating math package doesn't have
    NAN.

    We sold thousands of controllers and never fried a probe. Other
    peoples' controllers did.



    --

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Carlos E.R.@21:1/5 to Skybuck Flying on Tue May 3 23:11:08 2022
    On 2022-04-30 17:31, Skybuck Flying wrote:
    When exception masks are all enabled to stop the processor from throwing floating point exceptions the following calculation produces a somewhat strange result:

    0.0 / 0.0 = -nan

    (At least in Delphi).

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

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

    Problem is with the code, example:

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

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


    I have not read the entire thread, so maybe someone has already said it;
    but yes, NAN is correct in math, because 0/0 is "undefined" (think
    limits). It can be zero, one, any number, even infinite. So multiplying
    T·D can actually be 0·∞, which is again "undefined", so 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.


    --
    Cheers, Carlos.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to Lasse Langwadt Christensen on Wed May 4 09:15:20 2022
    On 02/05/2022 22:02, Lasse Langwadt Christensen wrote:
    mandag den 2. maj 2022 kl. 22.52.48 UTC+2 skrev Phil Hobbs:
    jla...@highlandsniptechnology.com wrote:
    On Sun, 1 May 2022 20:27:33 -0700 (PDT), whit3rd <whi...@gmail.com>
    wrote:

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

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

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

    0/0 = 0

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

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

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

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

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

    It should worry about the skill of the programmer who wrote the code.

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

    +1
    Or maybe just count it. Not doing the divide saves enough time to do
    something else that is *directly* under the programmers control.

    Divides particularly and sometimes multiplies have the possibility of
    overflow or underflow if their inputs are unfriendly.

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

    Division even on the current crop of fast processors is already so slow
    that explicitly defending against division by zero and the resulting
    trap handling recovery is invariably faster than the alternative.

    Many times you can prove that the divisor will not ever be zero but if
    you can't then you should decide exactly how to handle that exception.

    Division is roughly an order of magnitude slower than any of the other primitive operations on today's CPU's - it was even worse in the past.

    +,-,* now execute in a single cycle and in combination with branch
    prediction and speculative execution can appear to execute in fractions
    of a cycle provided that the data they need is available quickly enough.

    --
    Regards,
    Martin Brown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to Joe Gwinn on Wed May 4 09:49:04 2022
    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)

    I'm presently working on an algorithm that minimises divides to obtain
    higher speed - at least that was the original aim. Serendipitously I
    also found that then new schema simultaneously made the whole thing considerably more accurate as well as faster.

    Basically I can sometimes trade a hardware divide for a much more
    horrible algebraic expression involving the other fast primitive
    operations and still come out ahead on execution time and accuracy.

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

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

    The important question here is is the divide by zero a real singularity
    or as seems likely a coordinate transform singularity from taking
    bearings and ranges into and out of x,y,z Cartesian coordinates.

    Altaz telescope mounts have exactly the same problems as gun turrets.
    Limited slew rates and allowable angles. It gets singular near the
    zenith since the scope cannot spin fast enough to track the sky there.
    This is a weak singularity but it has to be avoided.

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

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

    But is it a true singularity or an artefact of how you are doing the
    computing? My instinct is that it is the latter or else it could only
    arise so rarely that taking the next set of measurements and processing
    them would get you out of the bind. I can see that there might be cases
    where the matrix inversion was singular for a single instant but that
    would only be true for that time slice.

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

    Clearly in a combat situation you can't afford to do anything other than
    reset the calculation and try again. Or if it is because you are naively calculating a value of tan(x) then set it to >10^18 and pray. That value
    being more than enough to ensure that x = pi to double precision.

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

    Every division in safety critical or mission critical code should be
    checked for whether or not it can fail divide by zero and what if
    anything should be done about it if it does.


    --
    Regards,
    Martin Brown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to '''newspam'''@nonad.co.uk on Wed May 4 06:31:24 2022
    On Wed, 4 May 2022 09:15:20 +0100, Martin Brown
    <'''newspam'''@nonad.co.uk> wrote:

    On 02/05/2022 22:02, Lasse Langwadt Christensen wrote:
    mandag den 2. maj 2022 kl. 22.52.48 UTC+2 skrev Phil Hobbs:
    jla...@highlandsniptechnology.com wrote:
    On Sun, 1 May 2022 20:27:33 -0700 (PDT), whit3rd <whi...@gmail.com>
    wrote:

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

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

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

    0/0 = 0

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

    If the denominator is not zero, as the numerator approaches zero, yes, in the limit, the result approaches zero. But if the numerator is not zero, as the denominator approaches zero, in the limit, the result approaches infinity. So why would 0/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.

    No, count the number of superconductive magnets that were damaged. The
    big ones had a spiral staircase to let users get to the top.

    Not doing the divide saves enough time to do
    something else that is *directly* under the programmers control.

    Divides particularly and sometimes multiplies have the possibility of >overflow or underflow if their inputs are unfriendly.

    Or use a saturating math package.



    --

    Anybody can count to one.

    - Robert Widlar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to '''newspam'''@nonad.co.uk on Wed May 4 06:26:48 2022
    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)

    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.

    In my heater code I divided by the square of the unregulated supply
    voltage to get fast line regulation onto the heater PWM. Since that
    voltage doesn't change much, I guess I could have multiplied by
    2*(32-V) or something, namely just correct for slope around the
    nominal supply voltage. Would have saved coding the divide, which I
    only used once.


    --

    Anybody can count to one.

    - Robert Widlar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Walliker@21:1/5 to jla...@highlandsniptechnology.com on Wed May 4 07:09:05 2022
    On Wednesday, 4 May 2022 at 14:31:37 UTC+1, jla...@highlandsniptechnology.com wrote:
    On Wed, 4 May 2022 09:15:20 +0100, Martin Brown
    <'''newspam'''@nonad.co.uk> wrote:

    On 02/05/2022 22:02, Lasse Langwadt Christensen wrote:
    mandag den 2. maj 2022 kl. 22.52.48 UTC+2 skrev Phil Hobbs:
    jla...@highlandsniptechnology.com wrote:
    On Sun, 1 May 2022 20:27:33 -0700 (PDT), whit3rd <whi...@gmail.com> >>>> wrote:

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

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

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

    0/0 = 0

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

    If the denominator is not zero, as the numerator approaches zero, yes, in the limit, the result approaches zero. But if the numerator is not zero, as the denominator approaches zero, in the limit, the result approaches infinity. So why would 0/
    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.
    No, count the number of superconductive magnets that were damaged. The
    big ones had a spiral staircase to let users get to the top.
    Not doing the divide saves enough time to do
    something else that is *directly* under the programmers control.

    Divides particularly and sometimes multiplies have the possibility of >overflow or underflow if their inputs are unfriendly.
    Or use a saturating math package.

    A more spectacular example of what can go wrong is the failure of
    an Ariane 5 rocket: https://web.archive.org/web/20000815230639/http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html

    "On 4 June 1996, the maiden flight of the Ariane 5 launcher ended in a failure. Only about 40 seconds
    after initiation of the flight sequence, at an altitude of about 3700 m, the launcher veered off
    its flight path, broke up and exploded.
    ...
    The internal SRI software exception was caused during execution of a data conversion
    from 64-bit floating point to 16-bit signed integer value. The floating point number which
    was converted had a value greater than what could be represented by a 16-bit signed integer.
    This resulted in an Operand Error.
    ...
    Although the source of the Operand Error has been identified, this in itself did not cause the
    mission to fail. The specification of the exception-handling mechanism also contributed to
    the failure. In the event of any kind of exception, the system specification stated that: the
    failure should be indicated on the databus, the failure context should be stored in an EEPROM
    memory (which was recovered and read out for Ariane 501), and finally, the SRI processor
    should be shut down.
    It was the decision to cease the processor operation which finally proved fatal."

    John

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From rbowman@21:1/5 to Martin Brown on Wed May 4 08:13:07 2022
    On 05/04/2022 02:15 AM, Martin Brown wrote:
    Division even on the current crop of fast processors is already so slow
    that explicitly defending against division by zero and the resulting
    trap handling recovery is invariably faster than the alternative.

    Many times you can prove that the divisor will not ever be zero but if
    you can't then you should decide exactly how to handle that exception.

    Division is roughly an order of magnitude slower than any of the other primitive operations on today's CPU's - it was even worse in the past.

    +,-,* now execute in a single cycle and in combination with branch
    prediction and speculative execution can appear to execute in fractions
    of a cycle provided that the data they need is available quickly enough.

    https://www.hpmuseum.org/srw.htm

    The Fridens had no protection for a divide by zero operation despite its sophistication. It would churn away until you unplugged it. I would hope
    we've learned something in 70 years.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to jrwalliker@gmail.com on Wed May 4 07:45:22 2022
    On Wed, 4 May 2022 07:09:05 -0700 (PDT), John Walliker
    <jrwalliker@gmail.com> wrote:

    On Wednesday, 4 May 2022 at 14:31:37 UTC+1, jla...@highlandsniptechnology.com wrote:
    On Wed, 4 May 2022 09:15:20 +0100, Martin Brown
    <'''newspam'''@nonad.co.uk> wrote:

    On 02/05/2022 22:02, Lasse Langwadt Christensen wrote:
    mandag den 2. maj 2022 kl. 22.52.48 UTC+2 skrev Phil Hobbs:
    jla...@highlandsniptechnology.com wrote:
    On Sun, 1 May 2022 20:27:33 -0700 (PDT), whit3rd <whi...@gmail.com>
    wrote:

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

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

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

    0/0 = 0

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

    If the denominator is not zero, as the numerator approaches zero, yes, in the limit, the result approaches zero. But if the numerator is not zero, as the denominator approaches zero, in the limit, the result approaches infinity. So why would 0/
    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.
    No, count the number of superconductive magnets that were damaged. The
    big ones had a spiral staircase to let users get to the top.
    Not doing the divide saves enough time to do
    something else that is *directly* under the programmers control.

    Divides particularly and sometimes multiplies have the possibility of
    overflow or underflow if their inputs are unfriendly.
    Or use a saturating math package.

    A more spectacular example of what can go wrong is the failure of
    an Ariane 5 rocket: >https://web.archive.org/web/20000815230639/http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html

    "On 4 June 1996, the maiden flight of the Ariane 5 launcher ended in a failure. Only about 40 seconds
    after initiation of the flight sequence, at an altitude of about 3700 m, the launcher veered off
    its flight path, broke up and exploded.
    ...
    The internal SRI software exception was caused during execution of a data conversion
    from 64-bit floating point to 16-bit signed integer value. The floating point number which
    was converted had a value greater than what could be represented by a 16-bit signed integer.
    This resulted in an Operand Error.
    ...
    Although the source of the Operand Error has been identified, this in itself did not cause the
    mission to fail. The specification of the exception-handling mechanism also contributed to
    the failure. In the event of any kind of exception, the system specification stated that: the
    failure should be indicated on the databus, the failure context should be stored in an EEPROM
    memory (which was recovered and read out for Ariane 501), and finally, the SRI processor
    should be shut down.
    It was the decision to cease the processor operation which finally proved fatal."

    John

    Exception handling, like a trap/interrupt on divide by zero or
    overflow, is a hazard. After all, the flight continues.

    Best to prevent exceptions by understanding the physical process.

    PC programs can announce the exception and crash. Planes and rockets
    really do crash.



    --

    Anybody can count to one.

    - Robert Widlar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Wed May 4 07:44:11 2022
    onsdag den 4. maj 2022 kl. 16.13.11 UTC+2 skrev rbowman:
    On 05/04/2022 02:15 AM, Martin Brown wrote:
    Division even on the current crop of fast processors is already so slow that explicitly defending against division by zero and the resulting
    trap handling recovery is invariably faster than the alternative.

    Many times you can prove that the divisor will not ever be zero but if
    you can't then you should decide exactly how to handle that exception.

    Division is roughly an order of magnitude slower than any of the other primitive operations on today's CPU's - it was even worse in the past.

    +,-,* now execute in a single cycle and in combination with branch prediction and speculative execution can appear to execute in fractions
    of a cycle provided that the data they need is available quickly enough.
    https://www.hpmuseum.org/srw.htm

    The Fridens had no protection for a divide by zero operation despite its sophistication. It would churn away until you unplugged it. I would hope we've learned something in 70 years.

    https://youtu.be/7Kd3R_RlXgc

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to rbowman on Wed May 4 12:30:14 2022
    rbowman wrote:
    On 05/04/2022 02:15 AM, Martin Brown wrote:
    Division even on the current crop of fast processors is already so slow
    that explicitly defending against division by zero and the resulting
    trap handling recovery is invariably faster than the alternative.

    Many times you can prove that the divisor will not ever be zero but if
    you can't then you should decide exactly how to handle that exception.

    Division is roughly an order of magnitude slower than any of the other
    primitive operations on today's CPU's - it was even worse in the past.

    +,-,* now execute in a single cycle and in combination with branch
    prediction and speculative execution can appear to execute in fractions
    of a cycle provided that the data they need is available quickly enough.

    https://www.hpmuseum.org/srw.htm

    The Fridens had no protection for a divide by zero operation despite its sophistication. It would churn away until you unplugged it. I would hope we've learned something in 70 years.

    Wow, an Italian tune-up for a desk calculator. ;)

    Cheers

    Phil Hobbs

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Wed May 4 09:54:19 2022
    On Wed, 4 May 2022 12:30:14 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    rbowman wrote:
    On 05/04/2022 02:15 AM, Martin Brown wrote:
    Division even on the current crop of fast processors is already so slow
    that explicitly defending against division by zero and the resulting
    trap handling recovery is invariably faster than the alternative.

    Many times you can prove that the divisor will not ever be zero but if
    you can't then you should decide exactly how to handle that exception.

    Division is roughly an order of magnitude slower than any of the other
    primitive operations on today's CPU's - it was even worse in the past.

    +,-,* now execute in a single cycle and in combination with branch
    prediction and speculative execution can appear to execute in fractions
    of a cycle provided that the data they need is available quickly enough.

    https://www.hpmuseum.org/srw.htm

    The Fridens had no protection for a divide by zero operation despite its
    sophistication. It would churn away until you unplugged it. I would hope
    we've learned something in 70 years.

    Wow, an Italian tune-up for a desk calculator. ;)

    Cheers

    Phil Hobbs

    I worked two summers at UNO, in a microwave spectroscopy project. I
    designed hv pulsers for Stark effect spectroscopy, with big hard tubes
    and thyratrons.

    Two grad students spent the entire summer in a tiny room with two
    Friden calculators calculating resonances. They did everything twice
    and cross-checked. My PC would do that now in milliseconds.

    I made 50 cents per hour and learned a lot. They could only pay
    students so they gave me fake student ID number 20,000 on the theory
    that they would never get that high. Some poor person is now confused
    with me.



    --

    Anybody can count to one.

    - Robert Widlar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to Martin Brown on Wed May 4 12:27:42 2022
    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.

    (I expect that Lasse was thinking more about the control loop stability problem--with constant coefficients, all the pole and zero frequencies
    are proportional to the update rate.)


    Many times you can prove that the divisor will not ever be zero but if
    you can't then you should decide exactly how to handle that exception.

    Division is roughly an order of magnitude slower than any of the other primitive operations on today's CPU's - it was even worse in the past.

    +,-,* now execute in a single cycle and in combination with branch
    prediction and speculative execution can appear to execute in fractions
    of a cycle provided that the data they need is available quickly enough.


    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to jlarkin@highlandsniptechnology.com on Wed May 4 13:32:07 2022
    jlarkin@highlandsniptechnology.com wrote:
    On Wed, 4 May 2022 12:30:14 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    rbowman wrote:
    On 05/04/2022 02:15 AM, Martin Brown wrote:
    Division even on the current crop of fast processors is already so slow >>>> that explicitly defending against division by zero and the resulting
    trap handling recovery is invariably faster than the alternative.

    Many times you can prove that the divisor will not ever be zero but if >>>> you can't then you should decide exactly how to handle that exception. >>>>
    Division is roughly an order of magnitude slower than any of the other >>>> primitive operations on today's CPU's - it was even worse in the past. >>>>
    +,-,* now execute in a single cycle and in combination with branch
    prediction and speculative execution can appear to execute in fractions >>>> of a cycle provided that the data they need is available quickly enough. >>>
    https://www.hpmuseum.org/srw.htm

    The Fridens had no protection for a divide by zero operation despite its >>> sophistication. It would churn away until you unplugged it. I would hope >>> we've learned something in 70 years.

    Wow, an Italian tune-up for a desk calculator. ;)

    Cheers

    Phil Hobbs

    I worked two summers at UNO, in a microwave spectroscopy project. I
    designed hv pulsers for Stark effect spectroscopy, with big hard tubes
    and thyratrons.

    Two grad students spent the entire summer in a tiny room with two
    Friden calculators calculating resonances. They did everything twice
    and cross-checked. My PC would do that now in milliseconds.

    I made 50 cents per hour and learned a lot. They could only pay
    students so they gave me fake student ID number 20,000 on the theory
    that they would never get that high. Some poor person is now confused
    with me.



    I doubt they issued any 1099s anyway, so no harm, no foul. ;)

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From whit3rd@21:1/5 to Phil Hobbs on Wed May 4 13:03:25 2022
    On Wednesday, May 4, 2022 at 9:27:55 AM UTC-7, Phil Hobbs wrote:
    Martin Brown wrote:

    Division even on the current crop of fast processors is already so 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.

    (I expect that Lasse was thinking more about the control loop stability problem--with constant coefficients, all the pole and zero frequencies
    are proportional to the update rate.)

    If you care about updating frequently, and if there's an issue with division, just... don't divide. Do everything with a lookup table; memory is cheap.
    Or, it's possible to take a multivariable equation into linear operation
    (a matrix operation instead of special functions) and a matrix operates on
    very simple formulae that don't include division or allow overflow.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From rbowman@21:1/5 to Lasse Langwadt Christensen on Wed May 4 21:07:50 2022
    On 05/04/2022 08:44 AM, Lasse Langwadt Christensen wrote:
    onsdag den 4. maj 2022 kl. 16.13.11 UTC+2 skrev rbowman:
    On 05/04/2022 02:15 AM, Martin Brown wrote:
    Division even on the current crop of fast processors is already so slow
    that explicitly defending against division by zero and the resulting
    trap handling recovery is invariably faster than the alternative.

    Many times you can prove that the divisor will not ever be zero but if
    you can't then you should decide exactly how to handle that exception.

    Division is roughly an order of magnitude slower than any of the other
    primitive operations on today's CPU's - it was even worse in the past.

    +,-,* now execute in a single cycle and in combination with branch
    prediction and speculative execution can appear to execute in fractions
    of a cycle provided that the data they need is available quickly enough.
    https://www.hpmuseum.org/srw.htm

    The Fridens had no protection for a divide by zero operation despite its
    sophistication. It would churn away until you unplugged it. I would hope
    we've learned something in 70 years.

    https://youtu.be/7Kd3R_RlXgc


    That's the animal. I don't remember the div stop but it's been a long
    time. I worked for the NYS Education Department summers in the mid-60's.
    NYS has state wide Regents exams which are designed from question pools
    to basically get a nice bell curve from the results. All the statistical
    number crunching was done on Fridens at the time.

    To answer the obvious question they sometimes did blow it and wind up
    flunking a lot of students leading to some post hoc juggling.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to All on Thu May 5 19:41:17 2022
    On 04/05/2022 21:03, whit3rd wrote:
    On Wednesday, May 4, 2022 at 9:27:55 AM UTC-7, Phil Hobbs wrote:
    Martin Brown wrote:

    Division even on the current crop of fast processors is already so 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.

    (I expect that Lasse was thinking more about the control loop stability
    problem--with constant coefficients, all the pole and zero frequencies
    are proportional to the update rate.)

    If you care about updating frequently, and if there's an issue with division, just... don't divide. Do everything with a lookup table; memory is cheap.

    Back then memory was (VERY) expensive and in short supply and machines
    with a hardware divide always had the advantage if you needed to use it.

    Or, it's possible to take a multivariable equation into linear operation
    (a matrix operation instead of special functions) and a matrix operates on very simple formulae that don't include division or allow overflow.

    Most of the tricks I know for special functions - some of which I still
    use rely on precisely one divide but with a bit of luck you can ensure
    that the parameters it is passed will never result in that happening.

    Polynomial functions with lousy convergence like eg log(x)

    log2(1+x) = x - x^2/2 + x^3/3 - ...

    x = -1/2 polysum3 = -2/3 -0.6666'
    x=1 Polysum3 = 5/6 0.8333'


    Pade approximation 3,2 of the above with one divide

    log2(1+x) = x*(6+x)/(6+4x)
    x = -1/2 pade3,2 = -11/16 -0.6875
    x = 1 PADE3,2 = 7/10 0.7

    The exact answer to 6 sig fig is 0.69315 so the Pade approximation is
    already good to 1% over the range -1/2 to 1 and <0.2% on -1/3 to +1/2.

    Something that has changed recently is that when a divide is pending
    other FP instructions that have no dependency on that particular result
    can execute in parallel making timing predictions very tricky indeed.

    --
    Regards,
    Martin Brown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to '''newspam'''@nonad.co.uk on Thu May 5 16:56:24 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to Phil Hobbs on Fri May 6 10:42:50 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tabby@21:1/5 to Skybuck Flying on Sun May 8 13:44:45 2022
    On Saturday, 30 April 2022 at 16:31:51 UTC+1, Skybuck Flying wrote:
    When exception masks are all enabled to stop the processor from throwing floating point exceptions the following calculation produces a somewhat strange result:

    0.0 / 0.0 = -nan

    (At least in Delphi).

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

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

    Problem is with the code, example:

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

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

    I find this very strange but ok.

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

    Bye for now,
    Skybuck.

    I can't remember where NAN is from, but it means the answer can not be computed.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to All on Sun May 8 17:47:48 2022
    On Sun, 8 May 2022 13:44:45 -0700 (PDT), Tabby <tabbypurr@gmail.com>
    wrote:

    On Saturday, 30 April 2022 at 16:31:51 UTC+1, Skybuck Flying wrote:
    When exception masks are all enabled to stop the processor from throwing floating point exceptions the following calculation produces a somewhat strange result:

    0.0 / 0.0 = -nan

    (At least in Delphi).

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

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

    Problem is with the code, example:

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

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

    I find this very strange but ok.

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

    Bye for now,
    Skybuck.

    I can't remember where NAN is from, but it means the answer can not be computed.

    It comes from IEEE Std 754, and NaN means only that the answer cannot
    be expressed as a real number (versus a poem or a picture), not that
    the answer cannot be computed.

    .<https://en.wikipedia.org/wiki/IEEE_754>

    Joe Gwinn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to All on Sun May 8 14:51:52 2022
    On Sun, 8 May 2022 13:44:45 -0700 (PDT), Tabby <tabbypurr@gmail.com>
    wrote:

    On Saturday, 30 April 2022 at 16:31:51 UTC+1, Skybuck Flying wrote:
    When exception masks are all enabled to stop the processor from throwing floating point exceptions the following calculation produces a somewhat strange result:

    0.0 / 0.0 = -nan

    (At least in Delphi).

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

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

    Problem is with the code, example:

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

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

    I find this very strange but ok.

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

    Bye for now,
    Skybuck.

    I can't remember where NAN is from, but it means the answer can not be computed.

    Not A Number.



    --

    Anybody can count to one.

    - Robert Widlar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tabby@21:1/5 to jla...@highlandsniptechnology.com on Wed May 11 15:23:07 2022
    On Sunday, 8 May 2022 at 22:52:03 UTC+1, jla...@highlandsniptechnology.com wrote:
    On Sun, 8 May 2022 13:44:45 -0700 (PDT), Tabby <tabb...@gmail.com>
    wrote:
    On Saturday, 30 April 2022 at 16:31:51 UTC+1, Skybuck Flying wrote:
    When exception masks are all enabled to stop the processor from throwing floating point exceptions the following calculation produces a somewhat strange result:

    0.0 / 0.0 = -nan

    (At least in Delphi).

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

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

    Problem is with the code, example:

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

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

    I find this very strange but ok.

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

    Bye for now,
    Skybuck.

    I can't remember where NAN is from, but it means the answer can not be computed.
    Not A Number.

    Yup. Though if we are to be pedantic, the correct answers generally are a number, but the CPU is unable to calculate or report them.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From none) (albert@21:1/5 to gnuarm.deletethisbit@gmail.com on Mon May 30 12:19:27 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to All on Mon May 30 11:42:05 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to Ricky on Mon May 30 09:04:52 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Mon May 30 10:02:19 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to lang...@fonz.dk on Mon May 30 10:43:04 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)