I guess the overlap between physicists/engineers and type system/PLT people isn’t large enough.
Also, why is there no CAD program that allows me to enter errors? When I try to model real objects, say a room, the lengths never add up 100% and I always have gaps once I'm around the room. It would be great to say all these measurements are ± 1 cm, this one is ± 5 cm, and these angles are 90° ± 1°. And then it would do least-squares, and give me a really accurate model, or tell me where I have to measure again.
Combine that with all of the other grandiose plans (writing extension in WASM) then it's no wonder that I wasn't making too much progress... interesting though!
C++ has supported units, as a library, since the early 90s. The Barton Nackman book had the initial implementation [1] and it was picked up years later by Scott Meyers [2].
[1] https://www.thriftbooks.com/w/scientific-and-engineering-c-a...
[2] https://stackoverflow.com/questions/28698558/c-dimensional-a...
https://pint.readthedocs.io/en/stable/
I'm sure it's not as good as a true type system could be, but it works pretty transparently due to Python's duck typing.
I’m literally in the middle of writing a rate limited continuously run service wrapper around some existing one shot task code and while I initially thought about just parsing the rate definition out myself because it’s pretty simple to just split on “/“ or “per”, but after thinking through the usage scenarios I just ended up using pint to convert anything it can understand as a frequency.
So anything of the form x / time unit or x per time unit, and converting it to the appropriate scale for use by the rest of my code. A whole bunch of string matching code replaced by a one line (two if I count the defensive unit type check to prevent false positive parsing problems) that looks as simple as this…
default_sleep_interval = (1/ureg(default_rate)).to(“seconds”).magnitudeThanks to Nim's strong type system and metaprogramming features, it allows for a fully compile time design, without any runtime overhead (in form of special unit objects or such things; everything is a `distinct float`).
In addition Nim's unicode support, the code even looks nice!
A more complex use case (I can link more if desired): [1]
[0]: https://github.com/SciNim/Unchained/
[1]: https://github.com/SciNim/Unchained/tree/master/examples
Here is a good in-depth comparison of the existing libraries:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p193...
https://package.elm-lang.org/packages/ianmackenzie/elm-units...
...which is used in other packages where unit type safety is important, such as elm-geometry:
https://package.elm-lang.org/packages/ianmackenzie/elm-geome...
So instead of float, we have (eg) float_meters, float_feet and so on.
Is there something that I'm missing here?
radius = 15 [mm]
area = pi*radius^3
force = 100 [N]
def will_i_blow_up(pressure [Pa]):
if(pressure > 1 [Gpa]):
return "Oh no it blew up"
will_i_blow_up( force/area )
area = pi*radius^2Math is a kind of a core use case for, really, almost any programming language, and is central to much of what computers are used for (as is hinted at in their name.)
Though dealing with this aspect of units is less “math-specific” than central to the relation between math and real-world meaning, which is arguably even more important than abstract math in computing applications.