[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

> >To: address@hidden
> >Subject: Service Message
> >Organization: College of Marine Studies, University of Delaware
> >Keywords: 199803190618.XAA22049

Hi Randy,

> I am currently writing some programs that 'pack' floating point
> values into BYTE and SHORT variables, but keep the 'scale_factor'
> and 'add_offset' attributes as FLOAT.
> 
> My question is about the valid_{min,max,range} attributes...
> 
> The NetCDF documentation says that 'valid_min', 'valid_max',
> and 'valid_range' should be the same type as the packed variable,
> but I'm finding it convenient to make them the same type as the
> 'scale_factor' and 'add_offset' attributes...
> 
> It would seem to me that the appropriate data-type for these
> attributes depends on whether one wants to do range-checking
> before or after scaling the variables..

The documentation in the User's Guide is in error in saying

  The type of each valid_range, valid_min and valid_max attribute should
  match the type of its variable ...

since the type conversion available with netCDF-3 makes this requirement
unnecessary.  We will delete that sentence from the next version of the
User's Guides.

You're right in pointing out that it's currently unclear whether the
intention was for the valid_{min,max,range} attributes to apply to the
data values before or after packing.  Since the library doesn't use
these attributes or treat them in any special way, you can use them
either way.  Unfortunately, since we didn't specify which way we
intended them to be used, there are probably existing conventions and
applications that conflict.  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.  So, if you are doing this for the first time, I would assume
that the valid_* values apply to the packed values.

We'll try to make this clearer in the next revision of the User's Guides.

I'd be interested if you find out about other developers who have
assumed the alternative convention in their applications or data.

--Russ

_____________________________________________________________________

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