Fortran - OT: What about NANs

Author

OT: What about NANs

Glyn Edwards

2005-09-21, 7:57 am

This is off topic but is along the same lines of "Why ... in Fortran?".
Can anyone give me a reason why it is a good idea for programs to carry on
after hitting producing a Nan? I ask because of the number of times I've
seen programs produce a Nan and then happily consume CPU resources adding
to it, multiplying by it etc and producing more Nans.

Is there ever a case when the Nan isn't a bug and if not wouldn't a better
default behavior be to crash at that point? I realise that compilers can
catch the nan with certain options but even in optimised code would it not
be better to crash rather than carry on using CPU cycles producing rubbish?

Can anyone enlighten me?

Glyn

Kevin G. Rhoads

2005-09-21, 7:57 am

>This is off topic but is along the same lines of "Why ... in Fortran?".
>Can anyone give me a reason why it is a good idea for programs to carry on
>after hitting producing a Nan?

First, it is on topic, sort of, but certainly not a Fortran issue, rather a floating
point issue (and, yes, I know one can create fixed point representations with NaNs,
but they are rare).

Next, if a routine generates an exception or interrupt, you need a handler to catch
it if you want to try to "fix" things in your code. If it generates an Inf or a NaN,
you can test for the value and try certain fixes. If you don't intend to test for
exceptional values, then masking the interrupts should not be done. But much of the
FPU (or simulator) set up stuff is done by run time library routines and never
over-ridden by the programmer.

Now if you are going to call a routine to compute a COT, you can test for 0.0 before
passing the argument in, certainly. But what of other inputs that produce singular
results? Argument decimation is an art form, should you reproduce all that in your
pretest? Alternatively you could try to catch the range error or whatever COT will
actually throw, but Fortran (and most languages) is not well suited for catching
interrupts and exceptions, and doing such will likely make your code less portable.

Or you can call COT and examine the return value for Infs and NaNs. Then all the argument
decimation is done in the library routine, presumably having been coded by experts
and exhaustively tested (no snickering in the peanut gallery!), but at least not
having to be coded by you.

Of course, there is always the stupid case -- turn off or mask out interrupts and
exceptions and don't bother to check return values for validity. But who said we
were intelligent?

Glyn Edwards

2005-09-21, 7:57 am

> Or you can call COT and examine the return value for Infs and NaNs. Then all the argument
> decimation is done in the library routine, presumably having been coded by experts
> and exhaustively tested (no snickering in the peanut gallery!), but at least not
> having to be coded by you.
So in a way it is a Fortran way for a routine to effectively throw and
exception (to use java terminology). That makes it seem more useful
although I'm still not convinced that making every routine cope with bad
inputs and output a Nan is a good thing.

Thanks

Glyn

Pierre Asselin

2005-09-21, 6:59 pm

Glyn Edwards <glynedwards@fastmail.fm> wrote:
> This is off topic but is along the same lines of "Why ... in Fortran?".
> Can anyone give me a reason why it is a good idea for programs to carry on
> after hitting producing a Nan?

I think one of the rationales was to produce tight loops for
pipelined CPUs. For example,

do i= 1, N
C(i)= A(i)/B(i)
end do

without explicitly testing for zeros in B(*). The compiler
can unroll the loop in such a way that several floating-point
divides are pending at any one time. Testing for B(i).eq.0
would break the simple structure and prevent pipelining, so
you don't. Later on you can test for NAN values in C(*)
and handle those appropriately.

Google for "IEEE 754" and you might find more detailed
(and correct) explanations.

--
pa at panix dot com

Richard E Maine

2005-09-21, 6:59 pm

In article <pan.2005.09.21.12.45.12.801492@fastmail.fm>,
Glyn Edwards <glynedwards@fastmail.fm> wrote:

> So in a way it is a Fortran way for a routine to effectively throw and
> exception (to use java terminology).

Yes, but... It is not standardized until the F2003 standard (or the IEEE
TR to f95). There have been vendor-specific ways for a long time, and
several current compilers implement the aforementioned TR.

I'll add one note to the comments made by others. Nobody seemed to
mention that there do exist cases in which infinities and NaNs
(particularly the infinities, but it can happen with the NaNs also) are
perfectly sensible results as part of a self-consistent arithmetic. I'll
admit that it isn't so for many typical engineering applications, so I
wouldn't call this the main reason for allowing NaNs to be generated.

But you did ask if there was "ever" a case where it is not a bug. The
answer to that is yes. There are cases where NaN is the correct answer
to a computation. This is in addition to the cases mentioned by others,
where NaNs can crop up in places that don't affect the result and thus
don't matter. I'm talking about cases where the NaN does matter, but it
is the correct result. Ok, they aren't typical of engineering
applications; but they exist.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Sponsored Links