6 ms·

Nitpicks: Why would your type system have encoded unit for kilo-pascal, but not hecto-pascal, mega-pascal, micro-pascal etc? If you only encode base units (e.

Nitpicks: Why would your type system have encoded unit for kilo-pascal, but not hecto-pascal, mega-pascal, micro-pascal etc? If you only encode base units (e.g. seconds), then we should use exact-precision arithmetic instead of f32 or f64, which is sometimes an overkill. If encoding all the modulos (kilo/milli/mega etc) I feel like there are some units may have name clashes (e.g. "Gy" -- is it giga-years, or gray)? Should we encode only SI units, or pounds/ounces/pints as well?

Ekaros 5y ago
Time units are messy. Once we get to Gigayears, what is the size of single year? Just 365 days? Or which of Julian, Gregorian, Tropical, Sidereal? At even kilo prefix the differences do add up. Or would you need to specify it? Days, weeks and months are also fun mess to think of.
- BlueTemplar 5y ago
  This is going to depend on the precision that you need. (Calculations without associated uncertainty calculations are worse than worthless anyway - misleading due to the inherent trust we tend to put in numbers regardless of whether they are garbage.)
- dragonwriter 5y ago
  > Once we get to Gigayears, what is the size of single year? The appropriate system of units is context-dependent. The astronomical system, for instance, has Days of 86,400 SI seconds and Julian years of exactly 365.25 Days; if you have a general and extensible units library, then this isn't really a difficulty, you just need to make a choice based on requirements.
Juliate 5y ago
Why wouldn't the type system be able to take care of that?
stinos 5y ago
(e.g. "Gy" -- is it giga-years, or gray) In my opinion this is not a real problem, since ideally no-one should such meaningless abbreviations in code. Just write giga_years or GigaYears or whatever your style is, problem solved, doesn't get any clearer than that.
- timthorn 5y ago
  In defence of Gy, it isn't meaningless in astronomy - it's a very well used unit. Though I do agree that it might be less common in code.
  - gattr 5y ago
    I myself can't remember seeing Gy in astronomical papers, but I've seen Ga (gigaannum). https://en.wikipedia.org/wiki/Year#SI_prefix_multipliers https://en.wikipedia.org/wiki/Year#SI_prefix_multipliers
    - timthorn 5y ago
      Ga is indeed used as well. https://en.wikipedia.org/wiki/Billion_years https://en.wikipedia.org/wiki/Billion_years
  - Aeolun 5y ago
    Isn’t Gy a bit much even in astronomy? With 15 Gy you have the age of the universe right?
    - em3rgent0rdr 5y ago
      Your comment piqued my curiosity, and I looked at https://en.m.wikipedia.org/wiki/Future_of_an_expanding_universe https://en.m.wikipedia.org/wiki/Future_of_an_expanding_unive... and found: "Stars are expected to form normally for 10^12 to 10^14 (1–100 trillion) years" So it seems Gy and even Ty units will be a reasonable scale for events during the period of star formation.
resonious 5y ago
I don't think the parent meant to exclude hecto-pascals from their hypothetical type system.
sparkie 5y ago
Does the type system handle equivalent units (dimensional analysis)? eg, N.m = kg.m^2.s^-2. Does the type system do orientational analysis? If not you to assign a value of work to a value of torque and vice versa, as they both have the above unit. There are several other similar gotchas with the SI. I think descriptive names are better than everyone attempting to implement an incomplete/broken type system.
- DiogenesKynikos 5y ago
  The Python package astropy does all these things. There's a graph of equivalencies between units. 0. https://docs.astropy.org/en/stable/units/index.html https://docs.astropy.org/en/stable/units/index.html
  - sparkie 5y ago
    I see dimensional analysis, but in this table[1], torque and work have the same unit, and that unit is J. The SI itself states[2]: "...For example, the quantity torque is the cross product of a position vector and a force vector. The SI unit is newton metre. Even though torque has the same dimension as energy (SI unit joule), the joule is never used for expressing torque." [1]:https://docs.astropy.org/en/stable/units/index.html#module-astropy.units.physical https://docs.astropy.org/en/stable/units/index.html#module-a... [2]:https://www.bipm.org/documents/20126/41483022/SI-Brochure-9-EN.pdf/2d2b50bf-f2b4-9661-f402-5f9d66e4b507 https://www.bipm.org/documents/20126/41483022/SI-Brochure-9-...
  - nuccy 5y ago
    Speaking of astropy units. I had a hilarious issue last week, which was quite hard to identify (simplified code to reproduce): from astropy import units as u a = 3 * u.s b = 2 * u.s c = 1 * u.s d = 4 * u.s m = min([a, b, c, d]) a -= m b -= m c -= m d -= m print(a,b,c,d) Output: 2.0 s 1.0 s 0.0 s 4.0 s Note the last 4.0, while min value is 1.0 The issue is that a, b, c, d are objects when astropy units are applied and min (or max) returns not the value but an object with the minimal value, thus m is c (in this particular case c has the smallest value) so c -= m makes m = 0, so d remains unchanged. It was very hard to spot especially when values change and occasionally either one of a, b, c or d has the smallest value. In-place augmentation of a working code with units may be very tricky and can create unexpected bugs.
usrusr 5y ago
You'll want to leave the point floating to floating point numbers, but whenever you interact with legacy APIs or protocols you want a type representing the scale they use natively. You wouldn't want to deal with anything based on TCP for example with only seconds (even if client code holds them in doubles), or with only nanoseconds. But you certainly won't ever miss a type for kiloseconds.
jltsiren 5y ago
The standard symbol for a year is "a". Using "y" or "yr" is non-standard and ambiguous, and they should be avoided in situations where precision and clarity matter.
- deepsun 5y ago
  Thanks, didn't know. Although in astronomy they use Gy often. PS: Don't know why people downvote, your comment is useful.
gpderetta 5y ago
Given a powerful enough type system, you can parameterize your types by the ratio to the unit and any exponent. Then you can allow only the conversions that make sense.
BlueTemplar 5y ago
Isn't floating point specifically for dealing with large orders of magnitude ? (Economics of floating vs fixed point chips might distort things though ?) Also, in the case that you meant this : you might need fractions of even base units for internal calculations : IIRC banking, which doesn't accept any level of uncertainty, and so uses exclusively fixed precision, uses tens of cents rather than cents as a base unit ?

Ekaros 5y ago

Time units are messy. Once we get to Gigayears, what is the size of single year? Just 365 days? Or which of Julian, Gregorian, Tropical, Sidereal? At even kilo prefix the differences do add up. Or would you need to specify it? Days, weeks and months are also fun mess to think of.

BlueTemplar 5y ago
This is going to depend on the precision that you need. (Calculations without associated uncertainty calculations are worse than worthless anyway - misleading due to the inherent trust we tend to put in numbers regardless of whether they are garbage.)
dragonwriter 5y ago
> Once we get to Gigayears, what is the size of single year? The appropriate system of units is context-dependent. The astronomical system, for instance, has Days of 86,400 SI seconds and Julian years of exactly 365.25 Days; if you have a general and extensible units library, then this isn't really a difficulty, you just need to make a choice based on requirements.

Juliate 5y ago

Why wouldn't the type system be able to take care of that?

stinos 5y ago

(e.g. "Gy" -- is it giga-years, or gray) In my opinion this is not a real problem, since ideally no-one should such meaningless abbreviations in code. Just write giga_years or GigaYears or whatever your style is, problem solved, doesn't get any clearer than that.

timthorn 5y ago
In defence of Gy, it isn't meaningless in astronomy - it's a very well used unit. Though I do agree that it might be less common in code.
- gattr 5y ago
  I myself can't remember seeing Gy in astronomical papers, but I've seen Ga (gigaannum). https://en.wikipedia.org/wiki/Year#SI_prefix_multipliers https://en.wikipedia.org/wiki/Year#SI_prefix_multipliers
  - timthorn 5y ago
    Ga is indeed used as well. https://en.wikipedia.org/wiki/Billion_years https://en.wikipedia.org/wiki/Billion_years
- Aeolun 5y ago
  Isn’t Gy a bit much even in astronomy? With 15 Gy you have the age of the universe right?
  - em3rgent0rdr 5y ago
    Your comment piqued my curiosity, and I looked at https://en.m.wikipedia.org/wiki/Future_of_an_expanding_universe https://en.m.wikipedia.org/wiki/Future_of_an_expanding_unive... and found: "Stars are expected to form normally for 10^12 to 10^14 (1–100 trillion) years" So it seems Gy and even Ty units will be a reasonable scale for events during the period of star formation.

resonious 5y ago

I don't think the parent meant to exclude hecto-pascals from their hypothetical type system.

sparkie 5y ago

Does the type system handle equivalent units (dimensional analysis)? eg, N.m = kg.m^2.s^-2. Does the type system do orientational analysis? If not you to assign a value of work to a value of torque and vice versa, as they both have the above unit. There are several other similar gotchas with the SI. I think descriptive names are better than everyone attempting to implement an incomplete/broken type system.

DiogenesKynikos 5y ago
The Python package astropy does all these things. There's a graph of equivalencies between units. 0. https://docs.astropy.org/en/stable/units/index.html https://docs.astropy.org/en/stable/units/index.html
- sparkie 5y ago
  I see dimensional analysis, but in this table[1], torque and work have the same unit, and that unit is J. The SI itself states[2]: "...For example, the quantity torque is the cross product of a position vector and a force vector. The SI unit is newton metre. Even though torque has the same dimension as energy (SI unit joule), the joule is never used for expressing torque." [1]:https://docs.astropy.org/en/stable/units/index.html#module-astropy.units.physical https://docs.astropy.org/en/stable/units/index.html#module-a... [2]:https://www.bipm.org/documents/20126/41483022/SI-Brochure-9-EN.pdf/2d2b50bf-f2b4-9661-f402-5f9d66e4b507 https://www.bipm.org/documents/20126/41483022/SI-Brochure-9-...
- nuccy 5y ago
  Speaking of astropy units. I had a hilarious issue last week, which was quite hard to identify (simplified code to reproduce): from astropy import units as u a = 3 * u.s b = 2 * u.s c = 1 * u.s d = 4 * u.s m = min([a, b, c, d]) a -= m b -= m c -= m d -= m print(a,b,c,d) Output: 2.0 s 1.0 s 0.0 s 4.0 s Note the last 4.0, while min value is 1.0 The issue is that a, b, c, d are objects when astropy units are applied and min (or max) returns not the value but an object with the minimal value, thus m is c (in this particular case c has the smallest value) so c -= m makes m = 0, so d remains unchanged. It was very hard to spot especially when values change and occasionally either one of a, b, c or d has the smallest value. In-place augmentation of a working code with units may be very tricky and can create unexpected bugs.

usrusr 5y ago

You'll want to leave the point floating to floating point numbers, but whenever you interact with legacy APIs or protocols you want a type representing the scale they use natively. You wouldn't want to deal with anything based on TCP for example with only seconds (even if client code holds them in doubles), or with only nanoseconds. But you certainly won't ever miss a type for kiloseconds.

jltsiren 5y ago

The standard symbol for a year is "a". Using "y" or "yr" is non-standard and ambiguous, and they should be avoided in situations where precision and clarity matter.

deepsun 5y ago
Thanks, didn't know. Although in astronomy they use Gy often. PS: Don't know why people downvote, your comment is useful.

gpderetta 5y ago

Given a powerful enough type system, you can parameterize your types by the ratio to the unit and any exponent. Then you can allow only the conversions that make sense.

BlueTemplar 5y ago

Isn't floating point specifically for dealing with large orders of magnitude ? (Economics of floating vs fixed point chips might distort things though ?) Also, in the case that you meant this : you might need fractions of even base units for internal calculations : IIRC banking, which doesn't accept any level of uncertainty, and so uses exclusively fixed precision, uses tens of cents rather than cents as a base unit ?