NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Chris, Having said that, NaN is usually "safer" in that its use causes error, >> making your bugs easier to spot. >> > > agreed, I like NaN as a fill value, but there's a downside -- NaN dpes not > equal NaN, so code that does: > > if something == fill_value: > > Will not work. It can be tricky. > That's exactly the reason for the "isnan()" function: if (isnan(fill_value)) . . . The Fortran language also includes such a function as part of its language standard: use:: ieee_arithmetic if (ieee_is_nan(fill_value)) then . . . In addition, Fortran compilers tend to include a compile option to enable "floating-point exception traps". If you enable the "invalid value" trap at the compile time, at the runtime, the program stops with an error message as soon as a NaN is generated or operated upon. This sometimes helps debug your code. Ryo
netcdfgroup
archives: