Now I understand what you mean by saying "1" and "8" can be used now.
However that workaround is a dead-end for user-friendliness, as
evidenced by my confusion as to the meaning of your suggestion.
And it does not accrue the UDUnits benefits of automagically
converting plain English prefixes to the numeric values, e.g.,
megabytes = 1000000 * bytes. No one wants to ask NCO to hyperslab
all data rates between 1.234e6 8's and 5.678e6 8's, nor
1.234 mega8's and 5.678e6 mega8's. That would be silly.
So. The case for including "bits" and "bytes" really makes itself.
Users would benefit if these common units of measurement were
integrated into UDUnits. Our case is an instrument that will fly on
a NASA satellite (ICESat2) and the Level1 datasets archive sensor
information and disk information like "bits per second" and "bytes per
second". Would be great if UDUnits-enable software could automatically
translate that into "megabytes per fortnight" and "decabits per day".
The ambiguity of whether byte should mean 8 bits (commonly accepted)
or should be reserved for the smallest addressable size on a given
architecture is worth noting. Octet does mean 8 bits, so that is
unambiguous. Nevertheless, people who deal with non-8-bit bytes
already know that the rest of the world thinks a bit is 8 bytes.
So byte = 8 bits is unlikely to adversely impact anyone.
Adopting this definition into UDUnits will help broaden its utility
in fields like electrical engineering, and computer science.
I looked into the Decimal vs. Binary (1000 vs. 1024) issue.
Seems pretty clear that Decimal is the way to go so mega means the
same for information as for SI units. "kibi"/"mebi" and friends
could be added for completeness.
From Charlie Zender at UCI:
Now I understand what you mean by saying "1" and "8" can be used now. However that workaround is a dead-end for user-friendliness, as evidenced by my confusion as to the meaning of your suggestion. And it does not accrue the UDUnits benefits of automagically converting plain English prefixes to the numeric values, e.g., megabytes = 1000000 * bytes. No one wants to ask NCO to hyperslab all data rates between 1.234e6 8's and 5.678e6 8's, nor 1.234 mega8's and 5.678e6 mega8's. That would be silly.
So. The case for including "bits" and "bytes" really makes itself. Users would benefit if these common units of measurement were integrated into UDUnits. Our case is an instrument that will fly on a NASA satellite (ICESat2) and the Level1 datasets archive sensor information and disk information like "bits per second" and "bytes per second". Would be great if UDUnits-enable software could automatically translate that into "megabytes per fortnight" and "decabits per day".
The ambiguity of whether byte should mean 8 bits (commonly accepted) or should be reserved for the smallest addressable size on a given architecture is worth noting. Octet does mean 8 bits, so that is unambiguous. Nevertheless, people who deal with non-8-bit bytes already know that the rest of the world thinks a bit is 8 bytes. So byte = 8 bits is unlikely to adversely impact anyone. Adopting this definition into UDUnits will help broaden its utility in fields like electrical engineering, and computer science.
I looked into the Decimal vs. Binary (1000 vs. 1024) issue. Seems pretty clear that Decimal is the way to go so mega means the same for information as for SI units. "kibi"/"mebi" and friends could be added for completeness.