Introducing Numbat: A programming language with physical units as types
Introducing Numbat: A programming language with physical units as types
Introduces the programming language Numbat and its type system
Introducing Numbat: A programming language with physical units as types
Introduces the programming language Numbat and its type system
F# has a feature kinda like this: https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/units-of-measure
Thought the same, plus you have the massive .NET Ecosystem.
This is a cool idea. There are other programming languages that have libraries that expose similar behavior. For instance, Rust has the uom crate, Haskell has the units package, and C++ has the header only library SI.
But there is something to be said about it being built in.
The web page says other libraries implement units whereas they implement dimensions. 1 cm and 1 inch has the same dimension, namely length, and you are able to add them together and get a correct result. seems nice. I don't know if it'll have any practical benefit but I like it.
I can't talk about the other libraries but the uom crate does the same thing.
The dimensions are encoded as a vector of generics, allowing you to get the correct unit even when dividing a distance by time for example.
It's quite the clever use of Rusts type system.
For sure. It'd be nice to have the units in a separate namespace but at least Numbat won't let you override identifiers already defined in the system of measure. I use Pint on Python - I usually keep the units in an identifier named u
so they can't get accidentally overridden. That means either using u.km
for single units or u('g/cm^3')
for composite units. It'd be great if the language could separate units e.g. as [km]
or `` but getting a compact syntax to distinguish the units namespace without colliding with other language features would be tricky. I remember F# having a good syntax but didn't dive that deep since it's not used widely in my field.
Wish I had this in engineering undergrad! Very cool.
I'm currently in engineering undergrad and this looks like it'll be a lifesaver. Wolfram Alpha can do some pretty good work with units sometimes. But a lot of the time it'll do weird stuff like refuse to interpret "V" as "volt", so you have to type out the full name of every single unit. This language should handle that a million times better.
I've always thought Frink (frinklang.org) looked pretty cool. It's been around forever. I've never used it though.
This would be so nice in a mainstream language, I wonder if it would be possible with rust's macro system?
The uom crate implements this for Rust.
The core functionality is based on generics but there are some macros for defining custom measurement systems.
I disagree.
I worked with a software for quantum physics and electronic transport from microscale to mesoscale. It had a "python based" DSL that had support for units through that module. Seems the perfect scenario for such entity, so we wrote it integrating another similar package (it's not the units package, I can't find it anymore. In any case, it let you say things like speed = 3 * meters / second)
The results were... interesting.
There are many major problems:
So, it looks cool, but in practice it's pointless. The only practice to follow is:
In other words:
user gives stuff in micrometers -> store it in length_um -> convert it in nanometers -> store it in length -> use length from now on (implicitly in nanometers)
The reverse for output
But all the downsides you mention are inherent to the problem, not to adding dimensions.
managing scales
How do you add a nanometer and a meter without units? You need to make the choice loss of precision vs convert to nanometer anyway. Types just give you reassurance that you did the right thing (at opposed to, say convert m to gigameter instead of nanometer, because you forgot a minus sign for the conversion).
Constants
A good unit system has the constants saved. I don't need to look up the dimensions of hbar in eV, I just do units.hbar and get the thing I mean, not the number that implicitly has a J or eV next to it. And if you have a constant that is not in the units library, you only need to define it once. This really isn't the problem you make it seem.
Logarithms
I am very curious where you take logarithms of measures with dimensions and why you cannot normalize to e.g. l/1m // length in meters
before taking the log. A unit system doesn't prevent you from doing this, it just makes it explicit what you implicitly did anyway (but didn't tell anyone else, because it's implicit)
Performance
This is a fair point and I will grant you that. If you do large scale simulations you need performance more than anything. But most math you do in science is a short script that I don't want to pour an hour into to make sure I didn't fuck up the units. I want to write the script, have the computer check the units and then take a break while the computer takes an hour to compute the result.
Units and namespaces
Not a big problem in my experience. The vast, vast majority of variables are derived. You don't need to write v = 3 * meters / second
, you have distance = 100 * meters
and time = 33 * seconds
somewhere in your code anyway, so you only need v = distance/time
. The assignment to v
is identical, if you have units or not. You only need to define the input, and only do it once.
normalized form
The units library simply allows you to choose. print(fuel_efficiency.in(1 * liter / (100 * kilometer))) // 5 l/100km
or print(fuel_efficiency.to_si_base_units()) // 5e-8 m**2
I have written code of the form xxxx_in_meV
, yyyy_in_per_cm_cubed
, etc before. It's much worse than a proper unit system library.
Because if you don't use a library you may be able to use a number for your constants - but you have to find out the value of your constants in some weird jumble of dimensions. It's the difference between target_efficiency = 5 * liter / (100 * km)
and target_in_metersquared = 5e-8 // 5 l/100km, converted to base units
Taking user input is much easier too. Just do units.parse(user_input)
, and the user is free to give um or nm or Å. No need for a prominent tip in the ui "input must be given in um!".
All that being said, a new language is not what I am looking for. I use python sympy (though it's not very ergonomic to use) for proper script programs and insect.sh if I need to convert something quickly.
EDIT: insect.sh tells its users to use numbat now, hahaha! numbat.dev has exactly the same UX though, so I'll just recommend that now for those quick physics calculations. It really is an invaluable tool to have.
I wonder if it would be possible with rust's macro system?
I don't know, but maybe check out numbat, it's a new scientific calculator that is written in rust.
Fascinating idea, that was an interesting read! Don't think I'd ever seen something like that done before.
There exist a bunch of libraries designed for kotlin using its extension methods and properties system to produce the same, like this one : https://github.com/vsirotin/si-units
Really cool! Reminds me a bit of the Numi calculator too
I do a lot of this stuff with the HP48 Units menu (albeit at this point via an emulator on my phone).
I would have loved to use that when I was studying physics
This looks like a lot of fun to use, I loved the example from What If, so many units!
Reminds me of Mathcad and Calca