I think it's valid to mention the history relating to signed and
unsigned types (and the lack of specificity).
This also raises a related issue that I was letting slide. :-)
In the paragraph below (which comes from the 'old' CF section), the
convention for indicating unsigned values only claims to be valid for
byte type. I know of numerous files "in the wild" that have unsigned
values stored in short (2-byte) integer variables. There is no reason
for the convention to be limited to byte type that I can see.
Explicitly allowing unsigned types somewhat obviates the need for the
convention moving forward, but it seems to me that the existing
convention is unnecessarily narrow.
Grace and peace,
Jim
On 9/21/17 12:54 PM, Charlie Zender wrote:
[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
convention
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
--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/>
/formerly NOAA’s National Climatic Data Center/
151 Patton Ave, Asheville, NC 28801
e: [email protected] <mailto:[email protected]>
o: +1 828 271 4900
/Connect with us on Facebook for climate
<https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
<https://www.facebook.com/NOAANCEIoceangeo> information, and follow us
on Twitter at @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
@NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
