Glenn writes:
>
> To recapitulate what you are saying, the problem in choosing the
> default fill values is that there are conflicting requirements:
>
> One wants them to be outside of or at the boundary of the
> range of the datatype so as not to be infringing on the
> user's space of possible data values.
>
> They need to be valid numbers on all platforms: eg, comparisons
> and such shouldn't cause core dumps or math exceptions.
> We got around this by making them different numbers on different platforms.
...
> The moral is: don't use the default fill values.
>
> Instead, set the variable specific attribute _FillValue to a value
> which is appropriate for your data.
I agree that the hooks were there with pre V1.11 netCDF (with the attribute
:missing_value) to *explicitly* set a missing value and the procedure is
improved now with _FillValue but this does not give one a useable (or at
least reproducible) fill value by default.
The system should be set up so that if you accept the *default* fill value
when writing a dataset, you should be able, on any subsequent platform,
to unabiguously determine which values are fill values.
If the moral was "don't use the default fill values" then the real moral is
redefine the default fill value to be something of general utility.
1. Using a value of NaN (illegal IEEE floating point number) internally
to netCDF satisfies your first condition that the number lie outside
the user's valid_range.
2. Using an internal fill value like this on all platforms means that the
data will always unambiguously carry with it its fill values, even in
the case that it was created with the default fill value.
If we redefine _FillValue for *output*, then this value will be
returned for missing data on that dataset on all platforms.
