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: jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>
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 _at_NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
_at_NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170921/563a9db4/attachment.html>
Received on Thu Sep 21 2017 - 11:25:00 BST
