[CF-metadata] Add new integer types to CF?
zender at uci.edu
Thu Sep 21 10:54:07 MDT 2017
[My previouse message confused bits with bytes in some locations.
This message is identical except it corrects the bit/byte confusion]
I did not address one of Dave Allured's comments:
"I suggest omitting the rest of this paragraph starting with "The
explicitly distinguishes ...". This topic is confusing, lacking context,
and I think unnecessary."
Basically Dave suggests eliminating the last half of this paragraph:
"The netCDF data types char, byte, unsigned byte, short, unsigned
short, int, unsigned int, int64, unsigned int64, float or real,
and double are all acceptable. The char type is not intended for
numeric data. One byte numeric data should be stored using the byte
or unsigned byte data type. It is possible to treat the byte type as
unsigned by using the NUG convention of indicating the unsigned range
using the valid_min, valid_max, or valid_range attributes. The
convention explicitly distinguishes between signed and unsigned
integer types only where necessary. Unless otherwise noted, int is
interchangeable with unsigned int, int64, and unsigned int64 in this
convention, including examples and appendices. Similarly short is
interchangable with unsigned short, and byte with unsigned byte."
The purpose of that half of the paragraph is to say that in the
rules/examples it is legal to replace an int with, say, an int64
or an unsigned int, etc _unless noted otherwise_. Meaning that the
CF 1.8 rules that use int32 in the examples do not require using
int32 in practice where any of uint32, int32, uint64, and int64 are
all legal. As it stands now, it is _never_ noted otherwise, because I
have not found a single convention where exchanging int types would be
bad. In that sense, the "unless noted otherwise" sentence is
superfluous. Yet it serves notice that people _should_ examine new CF
rules/examples to be sure that integer types in the rules/examples are
interchangeable. Sometime/somewhere a CF rule/example might _require_
an int32 not a uint32, or a uint64, not an int64.
So that's the purpose of the last half of the paragraph. Removing
it would make the paragraph leaner. In my opinion, it would also
be too loose in that readers would be left to _infer_ that
interchanging int types is explicitly sanctioned. Although sometimes
intentional ambiguity can be helpful. I don't feel strongly one way
or the other and will go with whatever consensus emerges on this.
Charlie Zender, Earth System Sci. & Computer Sci.
University of California, Irvine 949-891-2429 )'(
More information about the CF-metadata