Hey all,
I’m a big fan of the dimensional library, which allows for type-safe physical dimensions. I wrote a blog post about it.
Let me know what you think!
Additionally, I am now a maintainer of dimensional. I would love to hear about your experience so we can make it better.
I particularly like the derivation why arguments to sin etc. must be dimensionless.
One aspect where dimensions have helped me in exam situations was this: Given three (or more) units, dimension analysis often lets you derive the mathematical formula of the relationship of their quantities, e.g.
work = force * length
because
joule = newton * meter
One might envision a dimension-aware Djinn that can derive such formulas given the units.
How does dimensional deal with integrals and derivatives? Or is that subsumed by ordinary multiplication and division? Could it make sense to add Newton’s fluxions (infinitesimals) as an additional basic dimension? This would allow the scientific Haskeller to express differential equations in a type-safe way.
Given three (or more) units, dimension analysis often lets you derive the mathematical formula
That is indeed very cool! One of the reasons I wish radians were a base unit is to enable even more precise dimensional analysis (e.g. Planck’s constant and reduced Planck’s constant would have different dimensions).
How does
dimensionaldeal with integrals and derivatives?
Right now it doesn’t do analytical integrals and derivatives. For many numerical routines (e.g. Runge-Kutta), all you need are basic arithmetic operations.
I would love to see an ecosystem around dimensional; for example, supporting typed dimensions in the automatic differentiation ad package or quantities with uncertainties in the uncertain package.
This would be rather involved, since (*) and (/) for quantities is a lot more flexible than for the Num typeclass.
This is really great! One application I have in mind is hamiltonian monte carlo, which numerically solves an ODE to generate samples from a distribution. I implemented a version of this in Haskell, but it would be cool if I could distinguish between time and length on the type level. And for that matter, I’m working in phase space, so momentum and position should have different dimensions.
How does the dimensions package compare to units? For example, I wrote a physical model that also involves price calculations with a type-safe cost = price * quantity relationship. This is not derivable from SI Dimension.
I did not know about units! From the description (emphasis mine):
The units package provides a mechanism for compile-time dimensional analysis in Haskell programs. It defines an embedded type system based on units-of-measure. The units defined are fully extensible, and need not relate to physical properties.
That sounds very cool!
I’m not familiar with creating units in dimensional, but I think that the dimensions are restricted to the 7 basic physical dimensions (although dimensional is NOT limited to SI units, as seen in the OP)
In an ideal world, the SI Dimension can be part of the extensible units. Without having used either of the packages, there is one apparent obstacle:
Each value of type Dimension should serve as the associated type DimOfUnit of a SI unit and thereby give rise to an instance of the Data.Metrology.Unit class. However, the kind of DimOfUnit is * and not poly-kinded, as would be required if we were to use elements of the type Dimension as types. The corresponding SI dimensions definitions have an isolated type of kind * for every SI dimension.
Perhaps a poly-kinded DimOfUnit is worth an issue in the tracker of units? @rae what do you think? Is that feasible?
My favorite example of this sort is the period of a small-angle pendulum. What is the period T :: s of a pendulum with weight m :: kg, length l :: m and gravity g :: m / s^2? Immediately from dimensional analysis alone we see that weight cannot possibly have any effect on the period, and the only way to unify s = m^a (m / s^2)^b is b = -1/2 and a = 1/2, so T = c sqrt(l / g) for some coefficient c.
An opportunity to recall the classic example of the potential cost of getting units wrong in software: Mars Climate Orbiter - Wikipedia.
Also using dimensional in a project with roughly estimating plane weight and balance among other things – and can confirm it’s been great. Has helped avoid a lot of dumb mistakes. I made a small wrapper module around it that gives me the operators prefixed with a . since usually I’m still needing to do arithmetic on plain old Ints and such I find qualified operators everywhere are quite distracting/hard to read/write.
Just curious: Does there exist a solution for the boundary problem? That is, when an application imports data from file or network (the data crosses the outside world/application boundary), the numbers usually come without units. It it easy to shoot yourself in the foot by interpreting the raw numbers in the wrong unit. Apparently the mentioned Mars Orbiter failure was a boundary problem. This might warrant a Numeric.Units.Dimensional.Parser module.
That’s an excellent idea, I’ll see if there’s appetite to have this in the main dimensional repository
Edit: Add parsing functionality (possible in a new package) · Issue #230 · bjornbm/dimensional · GitHub