Stuff and NaN-sense

[Bob Masta]

Quick... what's X / X ?

If you hadn't read the subject line you would probably say
"1, of course!". Heck, you'd factor it out if you were
reducing an equation. But for the FPU the answer is "It
depends", because if X happens to be zero the returned
result is an INDEFINITE NaN, encoded as 50% more negative
than negative infinity. (!)

I've never found this FPU behavior to be helpful, and often
found it to cause problems. I can deal with it in
"built-in" code, but for macro-scripted code written by
users it seems too much to expect. So I'm thinking of
adding a special flag that can be set via macro, which will
normally default to returning unity in the 0/0 case, but can
be set to return either 0 or INDEFINITE if they really want
one of those.

My question for the group is whether there are hidden
"gotchas" that would make this a bad idea, or at least that
need special attention or cautions for the user.

FYI, This was prompted by a script that displays a rolling
"strip chart" of measured values, along with a floating
digital readout. The user wanted to see a "transfer
function"-type ratio (response voltage over driving
voltage), which normally only varies between 0 and a bit
more than 1.00.

But at initial start-up the driving voltage was 0 on the
first pass through the script, so the digital readout
flashed the biggest negative value it could show. That in
itself would not be a problem, except that the display
auto-sizes on the initial value and thereafter increases
only as needed, and never decreases (to prevent annoying
size jitter). So the user would be left with a super-wide
display filled with mostly white space until he manually
resized it. Ugly!

Thanks, and best regards,






Bob Masta

DAQARTA v7.21
Data AcQuisition And Real-Time Analysis
www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
Frequency Counter, Pitch Track, Pitch-to-MIDI
FREE Signal Generator, DaqMusic generator
Science with your sound card!

[Terje Mathisen]

Bob Masta wrote:
> Quick... what's X / X ?
>
> If you hadn't read the subject line you would probably say
> "1, of course!". Heck, you'd factor it out if you were
> reducing an equation. But for the FPU the answer is "It
> depends", because if X happens to be zero the returned
> result is an INDEFINITE NaN, encoded as 50% more negative
> than negative infinity. (!)

Dividing anything by zero is defined to give this result, it is only in
the 0/0 case taht you can argue that anything else would be correct, and
the proper answer in that case is basically that "it can be whatever you
want", depending upon how the two numbers got to zero.

>
> I've never found this FPU behavior to be helpful, and often
> found it to cause problems. I can deal with it in
> "built-in" code, but for macro-scripted code written by
> users it seems too much to expect. So I'm thinking of
> adding a special flag that can be set via macro, which will
> normally default to returning unity in the 0/0 case, but can
> be set to return either 0 or INDEFINITE if they really want
> one of those.

Returning 1 for the special case of 0/0 is probably a useful default for
many situations, the better one is to detect NaN as "Missing data" and
simply skip that point.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[Robert Redelmeier]

Bob Masta <N0S...@daqarta.com> wrote in part:

> But at initial start-up the driving voltage was 0 on the first
> pass through the script, so the digital readout flashed the
> biggest negative value it could show. That in itself would not
> be a problem, except that the display auto-sizes on the initial
> value and thereafter increases only as needed, and never decreases
> (to prevent annoying size jitter). So the user would be left
> with a super-wide display filled with mostly white space until
> he manually resized it. Ugly!

So initialize the floats with less stupid values.
-0.001 would sound good for this strip chart.

As an integer ZERO is valid and useful, but ZERO has dubious
value or validity as a float intended to represent real world
(or imaginary!) very large and very small numbers with precision
but not accuracy.

Voltage is never ZERO, even across an unloaded gold buss-bar.
It might be only picovolts or attovolts, but it is _NOT_ ZERO.


-- Robert

[Hugh Aguilar]

On Apr 17, 9:44 am, Terje Mathisen <"terje.mathisen at

tmsw.no"@giganews.com> wrote:
> Returning 1 for the special case of 0/0 is probably a useful default for
> many situations, the better one is to detect NaN as "Missing data" and
> simply skip that point.

I was wondering about this same question. My Forth interpreter is
going to have ratios as a built-in data-type (64-bit integer numerator
and denominator), so it is an issue for me.

I would consider 0 to be the correct answer. I hadn't even considered
1 at all. If the numerator is 0, then I return the result as 0 without
doing the division, and without looking at the denominator at all ---
this speeds up the code because it saves a division when the result is
0, and it provides what I consider to be the correct answer even when
the denominator is 0.

I don't think "infinity" is a valid answer, because there is no such
thing --- there is such a thing as "positive infinity" and "negative
infinity" --- but 0/0 is neither, as the numerator (0) is neither
positive nor negative.

[Tim Roberts]

Hugh Aguilar <hughag...@nospicedham.yahoo.com> wrote:
>
>I was wondering about this same question. My Forth interpreter is
>going to have ratios as a built-in data-type (64-bit integer numerator
>and denominator), so it is an issue for me.
>
>I would consider 0 to be the correct answer. I hadn't even considered
>1 at all. If the numerator is 0, then I return the result as 0 without
>doing the division, and without looking at the denominator at all ---
>this speeds up the code because it saves a division when the result is
>0, and it provides what I consider to be the correct answer even when
>the denominator is 0.

It's a tricky problem. 0 is NOT, in fact, the "correct answer". There is
no correct answer. That's why the usual result is "indefinite".

>I don't think "infinity" is a valid answer, because there is no such
>thing --- there is such a thing as "positive infinity" and "negative
>infinity" --- but 0/0 is neither, as the numerator (0) is neither
>positive nor negative.

Infinity (either one) is just as valid as 1 or 0. Consider inverting the
operation. If x = 0/0, then 0*x = 0. What value can you substitute for
"x" there? The answer is "any value you want".

If you don't have indefinites or NaNs, you can certainly have your
interpreter return 0, but be sure to document that, because many people
would be surprised by that.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

[Hugh Aguilar]

On Apr 21, 7:02 pm, Tim Roberts <t...@nospicedham.probo.com> wrote:

> Hugh Aguilar <hughaguila...@nospicedham.yahoo.com> wrote:
>
> >I was wondering about this same question. My Forth interpreter is
> >going to have ratios as a built-in data-type (64-bit integer numerator
> >and denominator), so it is an issue for me.
>
> >I would consider 0 to be the correct answer. I hadn't even considered
> >1 at all. If the numerator is 0, then I return the result as 0 without
> >doing the division, and without looking at the denominator at all ---
> >this speeds up the code because it saves a division when the result is
> >0, and it provides what I consider to be the correct answer even when
> >the denominator is 0.
>
> It's a tricky problem.  0 is NOT, in fact, the "correct answer".  There is
> no correct answer.  That's why the usual result is "indefinite".

You're right, there is no "correct" answer.

> If you don't have indefinites or NaNs, you can certainly have your
> interpreter return 0, but be sure to document that, because many people
> would be surprised by that.

It is best if I just throw an error, I suppose, rather than fudge it
with some made-up answer. No matter how I fudge it, it is going to be
wrong some of the time, and the error won't show up until later on, so
the user won't know where everything went haywire.

It is really the user's fault, so he deserves to get hit with an error
message! :-) As Robert Redelmeier said earlier, the user could have
just initialized with a tiny value, rather than with zero (although
that might result in overflow or underflow, which is another problem).

Thanks for pointing this out --- I hadn't really given it much
thought, but that would have been a subtle source of bugs in the
users' programs --- and that can result in the user saying: "Forget
about this compiler!" OTOH, if the user initializes with too small of
a value, and gets an overflow or underflow, then he will blame
himself, because he chose the value.