Opened 4 years ago

Last modified 3 years ago

#167 assigned enhancement

Use of valid_range to indicate unsigned integers

Reported by: Dave.Allured Owned by: Dave.Allured
Priority: medium Milestone:
Component: cf-conventions Version:
Keywords: unsigned integer deprecated Cc: dave.allured@…, zender@…

Description (last modified by Dave.Allured)

This responds to the recent request to add type short to the use of valid_range etc. to indicate unsigned integers.

Same as the proposed language in ticket #166, type short is included to document known usage. However, this proposal also suggests that this entire method for unsigned integers should be fully deprecated, in light of more straightforward and readily available storage methods.

The current CF 1.7 document, section 2.2 (Data Types) includes this sentence:

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.

Text of new proposal. Insert paragraph break, consistent with new paragraph breaks in ticket #166. Replace the sentence with this paragraph:

2.2.1  Unsigned Integers

It is possible to treat the byte and short types as unsigned
by using the NUG convention of indicating the unsigned
range using the valid_min, valid_max, or valid_range
attributes.  This usage is deprecated as of CF version
1.8.  Unsigned integer data should be stored with a signed
numeric type of sufficient range and precision, or with native unsigned
integers in one of the newer netCDF file formats.

Change History (5)

comment:1 Changed 3 years ago by Dave.Allured

  • Description modified (diff)
  • Owner changed from cf-conventions@… to Dave.Allured
  • Status changed from new to assigned

comment:2 Changed 3 years ago by zender

  • Cc zender@… added

Just adding myself to cc: list

comment:3 Changed 3 years ago by Dave.Allured

  • Type changed from defect to enhancement

comment:4 Changed 3 years ago by biard

I don't think the second sentence "However, the translation between signed and unsigned values is not well defined, and subject to interpretation." is necessary. I think the actual problem is that the signature is subtle and easy to miss, but I don't think we need to justify ourselves in this paragraph, no matter what objections we may have to the old way.

comment:5 Changed 3 years ago by Dave.Allured

  • Description modified (diff)

I removed that sentence. However I feel that either there should be a warning about possible interpretation, or else a sufficient definition of "interpreted as unsigned" should be added. I would be okay dropping the issue if you think this is sufficient.

Please feel free to directly modify the ticket and insert your own language.

Note: See TracTickets for help on using tickets.