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.
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.
Hi, Well, NetCDF specifies default fill values for all data types, so the most compliant solution is to one of those. Although I realise that this comment is off post. Cheers, Nick. Please consider email bloat when replying to this email ;-) Sent from Proton Mail Android -------- Original Message -------- On 22/04/2025 04:15, Ryo Furue wrote: > 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: