4 ms·

I think dimensions in physics serve as some interesting types, with their built-in arithmetics. I miss them in the languages I use (Python, TypeScript). I woul

by stared 7y ago

I think dimensions in physics serve as some interesting types, with their built-in arithmetics. I miss them in the languages I use (Python, TypeScript). I would love to have e.g. "percent" or "probability" type. So that when "100 percent === 1 probability", with proper autocasting. Same for quite a few other qualities (e.g. logit -(softmax)-> probabilities). Before I get "just use Haskell" or something in that line. IMHO for anything practical, ecosystem >>> language syntax and stuff. So the question is: are there any solid Python or TypeScript approaches for these systems?

leni536 7y ago
Probability is unitless. Percent is just literally 0.01 . Angle units have a similar problem.
- stared 7y ago
  I think you missed the point. Units != dimensions. E.g. angle in radians, degrees and full rotations differs by a factor. It is a typical, and common, mistake that would benefit from such system.
- quantified 7y ago
  All numeric concepts that have any meaning whatsoever have units/“dimensions”. Probability is in units of possible outcomes. If your chances are affected non-linearly, you’d express that (chance of death per inch of penetration). No percentages are unitless. If they were, you could substitute them without consequence, like applying an interest rate percentage in place of a mortality rate pecentage or an alcohol-to-water percentage. Angles, exponents, counts all fit in units, just more complex unit expressions.
- touisteur 7y ago
  Isn't the idea to mix types and dimensionality analysis? With mathematics libraries in a language like Ada your angles will usually be one type, your distances another, and the rate of change another, and so on.
ryanianian 7y ago
Python has operator-overloading, so you could imagine encoding some dimensionality into types such that `class Percent` has `__eq__` that knows about `class Probability` and similarly carry forward division or multiplication into runtime type info. I don't know of any libraries that do this with much success. Personally I would view such a thing as a cool demo (or a wild abuse of operators) but I could easily imagine it becoming infuriatingly difficult to analyze/debug if operations started returning outlandish units (`print(x/y) => 1 gallon/light-year`). My favorite tool for doing informal dimensional analysis is the `units` command-line utility. It is surprisingly adept. (It's a part of BSD and built into mac) $ units You have: meters/s You want: furlongs/fortnight * 6012.8848 / 0.00016630952
yunruse 7y ago
There is! The API is nowhere near complete, but Noether[0] can handle the following well: >>> display(lightsecond) >>> v = c / 3 >>> h / electron.mass / v (3.019×10⁻²⁰ ± 2.277×10⁻²⁸)ls <length, distance> >>> potrzebie / bushel 62.23m⁻² <vehicle efficiency> >>> print(f"The speed of light is about {c:.5e}") The speed of light is about c = 2.99792e+08m·s⁻¹ >>> momentum mass * length / time >>> print(flow) L³·T⁻¹ There's no explicit support for probability, but you can roll your own quick with some support >>> prob = Dimension.new(3.4, "probability", "P", "chance") >>> chance = Unit(prob) >>> percent = Unit(chance / 100, "%") >>> display(percent) >>> chance / 3 33.33% [0]: https://github.com/yunruse/noether https://github.com/yunruse/noether
mturmon 7y ago
I've used astropy.units in an intricate but medium-size (~10K LOC) Python simulator and it was really quite nice. You can do things like: import astropy.units as u import astropy.constants as const m1 = 1.0 * const.M_sun m2 = 150 * u.lb F = const.G*m1*m2 / (1.0 * u.au ** 2) print F.to('newton') where it has auto-converted the solar mass and the other mass to commensurate units, and then reduced the force into newtons. If you get the units wrong (e.g., use the wrong "g", or forget a mass when multiplying), it will be unable to convert to newtons and throw an exception. As you supposed, this proved to be a big benefit in a scientific code. Units checking removed a lot of worry when combining quantities from across the simulation, e.g., you didn't have to worry about how you were storing distances. A Matlab code shadowed some of the Python functions, and the difference in complexity/reliability was apparent. https://docs.astropy.org/en/stable/units/ https://docs.astropy.org/en/stable/units/

by stared 7y ago

leni536 7y ago

Probability is unitless. Percent is just literally 0.01 . Angle units have a similar problem.

stared 7y ago
I think you missed the point. Units != dimensions. E.g. angle in radians, degrees and full rotations differs by a factor. It is a typical, and common, mistake that would benefit from such system.
quantified 7y ago
All numeric concepts that have any meaning whatsoever have units/“dimensions”. Probability is in units of possible outcomes. If your chances are affected non-linearly, you’d express that (chance of death per inch of penetration). No percentages are unitless. If they were, you could substitute them without consequence, like applying an interest rate percentage in place of a mortality rate pecentage or an alcohol-to-water percentage. Angles, exponents, counts all fit in units, just more complex unit expressions.
touisteur 7y ago
Isn't the idea to mix types and dimensionality analysis? With mathematics libraries in a language like Ada your angles will usually be one type, your distances another, and the rate of change another, and so on.

ryanianian 7y ago

Python has operator-overloading, so you could imagine encoding some dimensionality into types such that `class Percent` has `__eq__` that knows about `class Probability` and similarly carry forward division or multiplication into runtime type info. I don't know of any libraries that do this with much success. Personally I would view such a thing as a cool demo (or a wild abuse of operators) but I could easily imagine it becoming infuriatingly difficult to analyze/debug if operations started returning outlandish units (`print(x/y) => 1 gallon/light-year`). My favorite tool for doing informal dimensional analysis is the `units` command-line utility. It is surprisingly adept. (It's a part of BSD and built into mac) $ units You have: meters/s You want: furlongs/fortnight * 6012.8848 / 0.00016630952

yunruse 7y ago

There is! The API is nowhere near complete, but Noether[0] can handle the following well: >>> display(lightsecond) >>> v = c / 3 >>> h / electron.mass / v (3.019×10⁻²⁰ ± 2.277×10⁻²⁸)ls <length, distance> >>> potrzebie / bushel 62.23m⁻² <vehicle efficiency> >>> print(f"The speed of light is about {c:.5e}") The speed of light is about c = 2.99792e+08m·s⁻¹ >>> momentum mass * length / time >>> print(flow) L³·T⁻¹ There's no explicit support for probability, but you can roll your own quick with some support >>> prob = Dimension.new(3.4, "probability", "P", "chance") >>> chance = Unit(prob) >>> percent = Unit(chance / 100, "%") >>> display(percent) >>> chance / 3 33.33% [0]: https://github.com/yunruse/noether https://github.com/yunruse/noether

mturmon 7y ago

I've used astropy.units in an intricate but medium-size (~10K LOC) Python simulator and it was really quite nice. You can do things like: import astropy.units as u import astropy.constants as const m1 = 1.0 * const.M_sun m2 = 150 * u.lb F = const.G*m1*m2 / (1.0 * u.au ** 2) print F.to('newton') where it has auto-converted the solar mass and the other mass to commensurate units, and then reduced the force into newtons. If you get the units wrong (e.g., use the wrong "g", or forget a mass when multiplying), it will be unable to convert to newtons and throw an exception. As you supposed, this proved to be a big benefit in a scientific code. Units checking removed a lot of worry when combining quantities from across the simulation, e.g., you didn't have to worry about how you were storing distances. A Matlab code shadowed some of the Python functions, and the difference in complexity/reliability was apparent. https://docs.astropy.org/en/stable/units/ https://docs.astropy.org/en/stable/units/