Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
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: