If there is a calculation whose result is NaN, how can I test for that?
The program goes on, and I only see it if I try to print the offending
number.
-- 
Dieter Britz (dieterhansbritz<at>gmail.com)

Dieter Britz <britz@chem.au.dk> wrote:

> If there is a calculation whose result is NaN, how can I test for that?
> The program goes on, and I only see it if I try to print the offending
> number.

If your compiler supports it,

      if(ieee_is_nan(x))  ...

-- glen

Dieter Britz wrote:
> If there is a calculation whose result is NaN, how can I test for that?
> The program goes on, and I only see it if I try to print the offending
> number.

There's probably some compiler flags that can help. E.g.

Wot now ? cat t.f90

Program test

   Implicit None

   Real :: a, b

   Read( *, * ) a
   Call sub( a, b )
   Write( *, * ) b

End Program test

Subroutine sub( a, b )

   Implicit None

   Real, Intent( In    ) :: a
   Real, Intent(   Out ) :: b

   b = Sqrt( a )

End Subroutine sub
Wot now ? gfortran t.f90 -o t
Wot now ? ./t
-1.0
              NaN
Wot now ? nagfor -C=all -gline t.f90 -o t
NAG Fortran Compiler Release 5.2(721)
[NAG Fortran Compiler normal termination]
Wot now ? ./t
-1.0
Runtime Error: *** Arithmetic exception: Floating invalid operation - 
aborting
t.f90, line 21: Error occurred in SUB
t.f90, line 9: Called by TEST
Aborted
Wot now ?

If it's not flags it's environnment variables, g95 works this way

Wot now ? g95 -ftrace=full -g t.f90 -o t
Wot now ? export G95_FPU_INVALID=true
Wot now ? ./t
-1.0
Floating point exception: Invalid operation
At line 21 of file t.f90
Traceback: (Innermost first)
    Called from line 9 of file t.f90


Even if you can't get an automatic traceback you can usually persuade it 
to dump core and then use a debugger. For instance I can't get gfortran 
to give me a proper traceback, don't quite know what I've done wrong, 
but with a few flags and a debugger I can get the line:

Wot now ? ulimit -c unlimited
Wot now ? gfortran -g -ffpe-trap=invalid -fbacktrace t.f90 -fdump-core -o t
Wot now ? ./t
-1.0

Program received signal 8 (SIGFPE): Floating-point exception.

Backtrace for this error:
   + [0xb7739400]
   + function test (0x8048700)
     at line 10 of file t.f90
   + /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb74df775]
Quit (core dumped)
Wot now ? gdb t core
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...

warning: Can't read pathname for load map: Input/output error.
Reading symbols from /usr/lib/libgfortran.so.3...done.
Loaded symbols for /usr/lib/libgfortran.so.3
Reading symbols from /lib/tls/i686/cmov/libm.so.6...done.
Loaded symbols for /lib/tls/i686/cmov/libm.so.6
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/tls/i686/cmov/libc.so.6...done.
Loaded symbols for /lib/tls/i686/cmov/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Core was generated by `./t'.
Program terminated with signal 3, Quit.
[New process 11695]
#0  0xb7739430 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7739430 in __kernel_vsyscall ()
#1  0xb74f49e6 in kill () from /lib/tls/i686/cmov/libc.so.6
#2  0xb767206d in ?? () from /usr/lib/libgfortran.so.3
#3  0xb7670d44 in ?? () from /usr/lib/libgfortran.so.3
#4  <signal handler called>
#5  0x08048770 in sub (a=@0xbf90c6e4, b=@0xbf90c6e0) at t.f90:21
#6  0x08048700 in test () at t.f90:9
#7  0x080487b9 in main ()
#8  0xb74df775 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#9  0x080485d1 in _start () at ../sysdeps/i386/elf/start.S:119
(gdb) quit


Ian

On 10/13/2010 5:49 AM, glen herrmannsfeldt wrote:
> Dieter Britz<britz@chem.au.dk>  wrote:
>
>> If there is a calculation whose result is NaN, how can I test for that?
>> The program goes on, and I only see it if I try to print the offending
>> number.
>
> If your compiler supports it,
>
>        if(ieee_is_nan(x))  ...
>
> -- glen
Long before compilers included such a library function, we made them 
ourselves.

logical function isnan(x)
real x
! shut off optimization by some compiler dependent instruction
!dir$ optimize(0)
isnan = x .ne. x
return
end

I use a partial implementation of ieee_arithmetic module which covers 
all the functions I need, via iso_c_binding, for compilers which don't 
implement it.  Perhaps it's an unpopular strategy, as it removes some 
incentive for a full implementation.
For example, I use ieee_set_underflow_mode() because the default mode is 
linked to compile-time optimization switches of various compilers.
-- 
Tim Prince

On 10/13/10 7:31 AM, Dieter Britz wrote:
> If there is a calculation whose result is NaN, how can I test for that?
> The program goes on, and I only see it if I try to print the offending
> number.
If you're not sure which calculation causes the first NaN, check the 
hardware/linker/compiler documentation.  There's often a way to turn on 
instant interrupts for IEEE invalid results at link/load time. 
Otherwise, look at IEEE_SET_HALTING_MODE.

Dick Hendrickson