4 ms·

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 assig

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.
  - necovek 5y ago
    That sounds like a bug in astropy type definitions: did you get a chance to report it as one? While it can sometimes be undefined behavior (a minimum of incompatible units), in cases like these it should DTRT.
  - DiogenesKynikos 5y ago
    This is really an issue with Python in general (specifically, mutable types). You'd get the exact same behavior with numpy ndarrays (of which astropy Quantities are a subclass).
    - dragonwriter 5y ago
      > This is really an issue with Python in general (specifically, mutable types). Unit-aware values as a type where assignment as mutation is an odd choice though (normal mutable types do not exhibit this behavior, it’s a whole separate behavior which has to be deliberately implemented.) It may make sense in the expected use case (and as you note reflects the behavior of the underlying type), but more generally it's not what someone wanting unit-aware values would probably expect.
  - deepsun 5y ago
    Mutable types are hard.
gpderetta 5y ago
This is the answer from boost units: https://www.boost.org/doc/libs/1_78_0/doc/html/boost_units/FAQ.html#boost_units.FAQ.Distinguishing_Quantities_With_Same_Units https://www.boost.org/doc/libs/1_78_0/doc/html/boost_units/F... tl;dr is uses some sort of pseudounits to make dimensionally similar but incompatible units, well, incompatible.

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.
- necovek 5y ago
  That sounds like a bug in astropy type definitions: did you get a chance to report it as one? While it can sometimes be undefined behavior (a minimum of incompatible units), in cases like these it should DTRT.
- DiogenesKynikos 5y ago
  This is really an issue with Python in general (specifically, mutable types). You'd get the exact same behavior with numpy ndarrays (of which astropy Quantities are a subclass).
  - dragonwriter 5y ago
    > This is really an issue with Python in general (specifically, mutable types). Unit-aware values as a type where assignment as mutation is an odd choice though (normal mutable types do not exhibit this behavior, it’s a whole separate behavior which has to be deliberately implemented.) It may make sense in the expected use case (and as you note reflects the behavior of the underlying type), but more generally it's not what someone wanting unit-aware values would probably expect.
- deepsun 5y ago
  Mutable types are hard.

gpderetta 5y ago

This is the answer from boost units: https://www.boost.org/doc/libs/1_78_0/doc/html/boost_units/FAQ.html#boost_units.FAQ.Distinguishing_Quantities_With_Same_Units https://www.boost.org/doc/libs/1_78_0/doc/html/boost_units/F... tl;dr is uses some sort of pseudounits to make dimensionally similar but incompatible units, well, incompatible.