Charlie, I like the central part of your proposal, in particular the first three sentences as shown.
I suggest omitting the rest of this paragraph starting with "The convention explicitly distinguishes ...". This topic is confusing, lacking context, and I think unnecessary. I suggest omitting all discussion of packing in favor of an independent discussion or ticket on this topic. That is also a tricky topic. First priority should be to simply get extended types into the conventions. --Dave On Fri, Sep 8, 2017 at 2:39 PM, Charlie Zender <[email protected]> wrote: > People, > > CF explicitly supports types char, byte, short, int, float, and double. > There are five "new" numeric types it could support: > unsigned byte, unsigned short, unsigned int, int64, and unsigned int64. > These new types are in netCDF3 (in the CDF5 encoding released in netCDF > v. 4.4.0) and in netCDF4. I suggest that CF 1.8 merge support for the > new numeric types. Please comment on this proposal. > > The current CF 1.8 draft reads (Section 2.2): > > "The netCDF data types char, byte, short, int, 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 data > type. All integer types are treated by the netCDF interface as > signed. 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." > > I suggest replacing that text with something like: > > "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." > > Section 8.1 on Packed Data currently reads: > > "An additional restriction in this case is that the variable > containing the packed data must be of type byte, short or int. It is > not advised to unpack an int into a float as there is a potential > precision loss." > > I suggest replacing that with something like: > > "An additional restriction in this case is that the variable > containing the packed data must be of type byte, short, or int. > Use of unsigned types to hold packed data is not permitted since > they are incapable of representing negative numbers. It is not > advised to unpack an int into a float as there is a potential > precision loss." > > The insertion of an Oxford comma in this last change is optional, > not intended to provoke an international incident. > > Unsigned, > Charlie >
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
