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 <zender at uci.edu> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170912/bd8b180f/attachment.html>
Received on Tue Sep 12 2017 - 15:33:33 BST
