Charlie,
Sounds good.
Jim
On 9/20/17 10:07 PM, Charlie Zender wrote:
> Two weeks ago I suggested adding new numeric atomic types to CF.
> There were two substantive responses:
>
> 1. Mary Jo Brodzik objected to this:
>
> "Use of unsigned types to hold packed data is not permitted since
> they are incapable of representing negative numbers."
>
> That statement is certainly objectionable because it is false.
> Both scale_factor and add_offset can be negative, so a positive
> or negative value can be packed into an unsigned integer.
> I can't think of any good reason to prohibit packing into unsigned.
> I concur with Mary Jo and think CF 1.8 should allow it.
> I no longer think Section 8.1 needs any modification.
>
> 2. Chris Barker questioned this proposed text:
>
> "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."
>
> In Chris' words, "So is there an unsigned byte type or not? if so, why
> bother with the text about valid-min, etc....?"
>
> That text on unsigned bytes is copied directly from Section 2.2.
> It defines and legitimizes the current practice of indicating that
> a value _stored_ as a signed byte (which is all that CF and netCDF
> CDF1 and CDF2 formats allow) should be _interpreted_ as an unsigned
> byte when the attributes valid_min and brethren say so.
> It seems to me that the text, though awkward, must be retained so
> that CF continues to permit the current practice for backwards
> compatibility. The CDF5 and netCDF4 binary formats both support
> unsigned bytes as atomic types, so there will be no _need_ to store
> unsigned bytes as signed bytes in those two formats. However, the
> current text that defines the current "unsigned workaround" must
> be included in CF 1.8 to continue to allow CDF1 and CDF2 formats
> to represent unsigned bytes. Otherwise we would be requiring all
> CF 1.8-compliant datasets with unsigned bytes to be stored in
> CDF5 or netCDF4. This minor proposal (new atomic types) is intended
> to provide new flexibility, not to force users of unsigned bytes to
> migrate from CDF1/2 to CDF5/netCDF4. Perhaps the wording could be
> improved but I thought it most straightforward to copy the text
> directly from the existing CF. I think the draft text I originally
> suggested for section 2.2 (datatypes) is appropriate.
>
> In light of these points, my revised suggested draft language
> to support new numeric atomic types would fit completely in Section
> 2.2 (datatypes) with no changes to Section 8.1 (Packing).
>
> 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."
>
> Unsigned,
> 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/0a198b68/attachment.html>
Received on Thu Sep 21 2017 - 06:37:18 BST
