Thanks, Andre. My approach to the problem is a spinoff of my work in air traffic control automation. It bothered me that scalar physical quantities are normally represented as numbers without explicit units. I’ve seen the errors where minutes get mistaken for seconds, degrees for radians and such. Sometimes those errors aren’t detected for a long time – like after a research paper is published – whoops! (I’m referring to a colleague here, of course, not me!) I originally developed my approach in Python, then I reimplemented it in Scala several years ago.
That is some interesting work you did 20 years ago. I skimmed your paper and may take a closer look at it later. It would be nice to have phusical dimensions represented as types and compatibility checks at compile time, but that is very difficult and beyond my level of expertise.
Jesper Nordenberg had that in his Metascala package a few years ago. As brilliant as it was how he used the Scala type system, however, his approach left a lot to be desired. Even though the unit compatibility checks were done by the compiler, the runtime performance was still very slow (by a factor of over 20 IIRC). Moreover, the actual physical units seemed to be a secret known only to the compiler. I couldn’t figure out how to get it to print unit information.
My approach has limitations, but I’m sure you will agree that it is preferable to raw dimensionless numbers.
My approach does not stop the user from defining multiple base units for length, for example. This could actually be considered a feature, I guess. (At one point I thought about defining separate length units for horizontal distance and altitude, since they are rarely combined in ATC, but I never actually did it.)
One of the most common errors in engineering and scientific computation involves mistaking degrees for radians. Using my scheme, one would write sin(30 * deg) to get the sin of 30 degrees. That is of course just a convenient way to do the standard conversion that is routinely done – but often forgotten. A while back, I decided that the trig functions should reject any argument that is not explicitly converted to radians. But radians are dimensionless, and trying to enforce a named unit for it caused other problems (relating to the implicit conversion of a Double to a dimensionless Scalar). I eventually abandoned that effort to force the user to explicitly convert the trig arguments to radians.
In any case, let me know if you have any other suggestions or ideas.