Subject: hpff-core: NaNs Happen

From: Rob Schreiber <[email-masked]>
Date: Mon, 6 Jan 1997 15:46:50 -0800 (PST)

---------------------------------------------------------------------------
[email-masked] is a mailing list for announcements related to High
Performance Fortran.  Instructions for adding or deleting yourself
from this list appear at the bottom of this message.
---------------------------------------------------------------------------
Dear HPFF:

As usual, there is something of substance that has appeared at the last minute.

I've been considering what we can/should say about the behavior of HPF
library routines in the presence of NaNs in the input.  This in response
to a question from Henry.

My first reaction was to ignore NaNs, as does the Fortran standard.
However, I brought up the question with Jim Demmel and Velvel Kahan.
And I asked Guy about how Java treats NaNs in its library routines.
Now, better educated on this subject, I want to make a proposal.

Kahan asks that we not ignore NaNs.  The reason for saying something is
to allow users to write portable code; they must have some behavior on
which they can rely.

There is no problem with the elemental functions.  SQRT(NaN) is NaN.
The Fortran standard doesnt say this, as NaN is not included in its model for 
REAL values, but is seems to me that it goes without saying.

For the reductions PROD, SUM, the IEEE rule dictate a NaN result when any
of the array elements contributing to an element of the result is a NaN.
Again, it seems to me that we don't have to say this.

Trouble comes from MIN, MAX, MINVAL, MAXVAL, SORT_UP, SORT_DOWN, GRADE_UP, and
GRADE_DOWN.    The IEEE standard has no simple answer to the question of
how NaNs compare with other numbers or other NaNs.

Here is Guy's input concerning what Java does:

  "In Java, if either argument to max() or min() is NaN, the result is NaN."

  "Java has no position on SORT or GRADE.  I would recommend that, for
   sorting purposes, NaN values should sort high with respect to finite
   values.  A simple way to achieve this is to convert each
   floating-point number to a signed integer of the same size and then
   grade the integers (or sort them and convert back).  The necessary
   conversion can be expressed in Java as:

        long j = Double.doubleToLongBits(x);
        if (j < 0) j ~= 0x7FFFFFFFFFFFFFFF;
        j -= 0x000FFFFFFFFFFFFF;

    which is clearly invertible.  This does cause the "negative" NaNs to sort
    higher than the "positive" NaNs---I don't think that matters; or a slightly
    more complex conversion can be used."

Before we agree with the first of these decisions, so that maxval,
minval, max, min (these are Fortran intrinsics, BTW) would all return
NaN whan any of the elements of the input corresponding to an element of
the result is NaN, we should look at an alternative:  the result is
always in the range [-Inf, +Inf].  NaN's play no role in determining the
value of the result.  Thus:

MAX(5, NaN) == 5
MIN(5, NaN) == 5
MAX(NaN, NaN) = -Inf   ! As if of an empty set

(And note that Guy's nice implementation of sort doesnt work for the Java
interpretation of MIN.)

For the SORT routines, I don't like the definition NaN > +Inf, as it's not
consistent with the behavior of MIN and MINVAL, and its wierd mathematically.  
I would prefer to put the NaNs at the end of the output, regardless of the
direction of the sort.  But that complicates Guy's implementation.

Lastly, I suggest an elemental function ISAN that returns .true. if its input is 
not a NaN and .false. otherwise.

We need to add NaNs to the HPF model for reals.   Something like
"A variable of type real may also have a value that does not represent any real
number.   Such a value is referred to as a NaN (Not a Number).  

The unary and binary operators that return real values will, in general,
return a NaN if any of their arguments is a NaN.  This is also true of
the intrinsic elemental and reduction functions.   Thus, for example, an element
of the result of SUM(X) will be a NaN if any element of X that contributes to that
element of the result is a NaN.

The behavior of MIN, MAX, MINVAL, MAXVAL in the presence of NaNs is as follows.
TBD.

The SORT and GRADE functions of the HPF_LIBRARY also behave in a deterministic way
when NaNs occur as elements of their inputs.   (How is TBD).

We could also just ignore NaNs and hope that the Fortran committee and some future
HPFF will get this right.

  -- Rob

--PAA17142.852594247/palrel1.hp.com--

---------------------------------------------------------------------------
To (un)subscribe to this list, send mail to [email-masked].
Leave the subject line blank, and in the body put the line
(un)subscribe <email-address>
---------------------------------------------------------------------------

---

From: Chuck Koelbel <[email-masked]>
Date: Tue, 7 Jan 1997 09:26:59 -0600

>Now, better educated on this subject, I want to make a proposal.

I agree with your analysis, but I think that practical reasons we should
just stick with "the default behavior", i.e. ignore NaNs.  My reasons:

* There is more than one reasonable alternative, as you analyze.

* NaN is not in the Fortran model for real numbers, so adding it would
essentially be changing the numerics of the language (in a small way).

* We cannot meet to discuss this before the draft is presented to the public.

The interpretation of NaN is a reasonable question to send to
hpff-interpret (priming the CCI pump for HPFUG).  It is an even better
question to send to X3J3.  But if the issue is important we should not
shoot from the hip in resolving it.

						Chuck

**********************************************************************
Charles Koelbel				CRPC, MS 132
Center for Research on Parallel Computation		Rice University
Rice University				6100 Main Street
[email-masked]				Houston, TX 77005
**********************************************************************