On Mon, 16 Mar 1998 Randy Zagar wrote in ncdigest Volume 01 : Number 445:
> Subject: 'valid_min', 'valid_max', and 'valid_range' question
>
> 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...
The section headed 'valid_range' includes the following sentence:
"The type of each valid_range, valid_min and valid_max attribute should match
the type of its variable (except that for byte data, these can be of a signed
integral type to specify the intended range)."
Note that this exception for type byte allows such data to be treated as
either signed or unsigned.
It you scale using attributes scale_factor and add_offset then it is
essential to note that the valid range applies to the external packed values
not the internal unpacked values.
For example, say you want to store (internal) values ranging from -3.0 to +3.0
using netCDF type short. You could set
scale_factor = 1.0e-4f
valid_min = -30000s
valid_max = 30000s
where the suffix f means float & s means short.
> 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..
Are you suggesting following?
valid_min = -30000.0f
valid_max = 30000.0f
This contravenes the conventions, but will usually work OK with version 3 due
to automatic type conversion.
Or are you suggesting following?
valid_min = -3.0f
valid_max = 3.0f
This implies that there are only seven valid external (short) values:
-3, -2, -1, 0, 1 ,2, 3
which correspond to unscaled values -0.0003 to 0.0003!
Note that the fact that the data-type of the valid range attributes is float
does NOT imply that these correspond to internal (float) values! In most
cases (using version 3 which does automatic type conversion) the reading
program does not need to worry about the external data-type.
I hope this clarifies these conventions.
Harvey Davies, CSIRO Mathematical and Information Sciences,
Email: harvey.davies@xxxxxxxxxxxxx
Phone: +61 3 9669 8110 or +61 3 9239 4556
Fax: +61 3 9669 8112
