Re: 980319: 'valid_min', 'valid_max', and 'valid_range' question

Randy,

Sorry it's taken me so long to respond to your note.

> >                  Harvey Davies (who replied earlier on the
> > netcdfgroup mailing list) helped us clarify the User's Guide
> > conventions, and it was his intention that the valid_* attributes apply
> > to the packed values, not the unpacked values.  This is also required by
> > the use of valid_* attributes to determine if bytes should be
> > interpreted as signed or unsigned when doing arithmetic to unpack
> > values.
> 
> I haven't had much time to formulate a complete response to Harvey's
> (and others) comments.  But...
> 
> I was under the impression that the 'signedness' attribute was supposed
> to be used to indicate whether we are dealing with [-127,+127] or [0,255].

The 'signedness' attribute proposed in the netCDF 2.3 User's Guide was
deemed to be a mistake and deprecated in all the subsequent User's
Guides.  For example, here's how it is described in the current netCDF C
User's Guide at 
<http://www.unidata.ucar.edu/packages/netcdf/guidec/guidec-13.html>.

    Deprecated attribute, originally designed to indicate whether byte
    values should be treated as signed or unsigned. The attributes
    valid_min and valid_max may be used for this purpose. For example,
    if you intend that a byte variable store only nonnegative values,
    you can use valid_min = 0 and valid_max = 255. This attribute is
    ignored by the netCDF library.

> I've also been thinking about _FillValue for signed bytes and shorts...
> This is entirely rhetorical, but it turns out that -128 (or -32768) is
> representable in a signed byte (short) and could be used for a _FillValue.

Yes, very early in the history of netCDF we mistakenly chose -127
instead of -128 as the default fill value for bytes, and backwards
compatibility has preserved that mistake for posterity.  

With netCDF-3 we declared that the netCDF byte type would be treated as
signed in the library for the purposes of converting to other types in
the new type conversion interfaces.  

--Russ

_____________________________________________________________________

Russ Rew                                         UCAR Unidata Program
address@hidden                     http://www.unidata.ucar.edu