Take the 2-minute tour ×

A Measured value consists of (typically nonnegative) floating-point number and unit-of-measure. The point is to represent real-world quantities, and the rules that govern them. Here's an example:

scala> val oneinch = Measure(1.0, INCH)
oneinch : Measure[INCH] = Measure(1.0)
scala> val twoinch = Measure(2.0, INCH)
twoinch : Measure[INCH] = Measure(2.0)
scala> val onecm = Measure(1.0, CM)
onecm : Measure[CM] = Measure(1.0)
scala> oneinch + twoinch
res1: Measure[INCH] = Measure(3.0)
scala> oneinch + onecm
res2: Measure[INCH] = Measure(1.787401575)
scala> onecm * onecm
res3: Measure[CMSQ] = Measure(1.0)
scala> onecm * oneinch
res4: Measure[CMSQ] = Measure(2.54)
scala> oncem * Measure(1.0, LITER)
console>:7: error: conformance mismatch
scala> oneinch * 2 == twoinch
res5: Boolean = true

Before you get too excited, I haven't implemented this, I just dummied up a REPL session. I'm not even sure of the syntax, I just want to be able to handle things like adding Measured quantities (even with mixed units), multiplying Measured quantities, and so on, and ideally, I like Scala's vaunted type-system to guarantee at compile-time that expressions make sense.

My questions:

  1. Is there extant terminology for this problem?
  2. Has this already been done in Scala?
  3. If not, how would I represent concepts like "length" and "length measured in meters"?
  4. Has this been done in some other language?

A $330-million Mars probe was lost because the contractor was using yards and pounds and NASA was using meters and newtons. A Measure library would have prevented the crash.

share|improve this question
Why do you get a conformance mismatch when multiplying a length and a volume? Why isn't this just a unit in m^4? –  oxbow_lakes Dec 2 '10 at 13:03
good catch oxbow. Maybe he meant to use a plus or minus sign there? –  I82Much Dec 2 '10 at 22:14
No, I was just grasping for an example of incommeasurability. I guess m^4 is theoretically proper, although no use for it comes readily to mind. As I82much pointed out, subtracting length from volume would be a better example. –  Malvolio Dec 2 '10 at 23:32
I have thought about it myself. You can certainly implement this in Scala, along with implicit conversions between units and what not. What I was not able to conceive is a syntax that comes close to the one in F# (without changing the Scala language). –  Raphael Feb 17 '11 at 21:07

6 Answers 6

up vote 5 down vote accepted

Well, this functionality exists in Java, meaning you can use it directly in Scala.

jsr-275, which was moved to google code. jscience implements the spec. Here's a good introduction. If you want a better interface, I'd use this as a base and build a wrapper around it.

share|improve this answer
Thanks, this is exactly what I was looking for. And given that I guessed very close to the correct terminology, thanks also for not giving me a lmgtfy link. –  Malvolio Dec 2 '10 at 23:30
Excellent, glad I could be some help. –  I82Much Dec 3 '10 at 15:53

F# has support for it, see for example this link for an introduction. There has been some work done in Scala on Units, for example here and here. There is a Scala compiler plugin as well, as described in this blog post. I briefly tried to install it, but using Scala 2.8.1, I got an exception when I started up the REPL, so I'm not sure whether this plugin is actively maintained at the moment.

share|improve this answer
It isn't. (Maintained.) –  extempore Dec 2 '10 at 7:38
I tried the scala units plugin and it didn't work in 2.9 either –  Luigi Plinge Jul 11 '11 at 23:06

Your question is fully answered with one word. You can thank me later.

FRINK. http://futureboy.us/frinkdocs/

share|improve this answer

Let me clarify my previous post. I should have said, "These kinds of errors ["meter/yard conversion errors"] are automatically AVOIDED (not "handled") by simply using my Scalar class. All unit conversions are done automatically. That's the easy part.

The harder part is the checking for unit inconsistencies, such as adding a length to a velocity. This is where the issue of dynamic vs. static type checking comes up. I agree that static checking is generally preferable, but only if it can be done without sacrificing usability and convenience.

I have seen at least two "projects" for static checking of units, but I have never heard of anyone actually using them for real work. If someone knows of a case where they were used, please let me know. Until you use software for real work, you don't know what sorts of issues will come up.

As I wrote above, I am currently using my Scalar class (http://russp.us/scalar-scala.htm) for my R&D work in ATC. I've had to make many tweaks along the way for usability and convenience, but it is working well for me. I would be willing to consider a static units implementation if a proven one comes along, but for now I feel that I have essentially 99% of the value of such a thing. Hey, the vast majority of scientists and engineers just use "Doubles," so cut me some slack!

share|improve this answer
Hello Russ, These aren't "posts" but are actually answers to the question. THey get voted on so that good answers bubble up to the top. If you would like to clarify your previous answer, you may want to edit it instead, but given that this answer has more votes, I'd suggest adding those changes into this one so you don't lose points. Taken together, you have a very good answer! Stackoverflow is not like a normal forum. You might want to take a look at the faq: stackoverflow.com/faq –  Ape-inago Dec 3 '12 at 2:34

"Yeah, ATC software with run-time type checking? I can see headlines now: "Flight 34 Brought Down By Meter/Yard Conversion"."

Sorry, but you don't know what you're talking about. ATC software is tested for years before it is deployed. That is enough time to catch unit inconsistency errors.

More importantly, meter/yard conversions are not even an issue here. These kinds of errors are automatically handled simply by using my Scalar class. For those kinds of errors, you need neither static nor dynamic checking. The issue of static vs. dynamic checking comes up only for unit inconsistencies, as in adding length to time. These kinds of errors are less common and are typically caught with dynamic checking on the first test run.

By the way, the interface here is terrible.

share|improve this answer
The interface will be better once you gain some reputation points and the system trusts you. You can do that by posting answers that actually address the question being asked. More info here: stackoverflow.com/faq –  Robert Harvey Feb 19 '11 at 16:31
@Robert -- Russ was the victim of a specific bug in the StackExchange software: when writing an answer, the Enter key causes a newline to be inserted into the text; when writing an comment, it actually submits the comment. –  Malvolio Feb 20 '11 at 17:19
I certainly know nothing about ATC software, but I know a thing or two about software in general, and I know that testing is no panacea. See my original question for an example of a system that was "tested for years before it is deployed" nonetheless having a bug that resulted in the loss of the vessel and the mission. Even if it were effective, testing has huge problems of its own. The FAA has been struggling for decades to get replace its 40-year-old HOST system with the only-slightly-out-of-date ERAM system and among its top-10 problems is testing. –  Malvolio Feb 20 '11 at 17:29

FYI, I have developed a Scalar class in Scala to represent physical units. I am currently using it for my R&D work in air traffic control, and it is working well for me. It does not check for unit consistency at compile time, but it checks at run time. I have a unique scheme for easily substituting it with basic numeric types for efficiency after the application is tested. You can find the code and the user guide at


Here is the summary from the website:

Summary-- A Scala class was designed to represent physical scalars and to eliminate errors involving implicit physical units (e.g., confusing radians and degrees). The standard arithmetic operators are overloaded to provide syntax identical to that for basic numeric types. The Scalar class itself does not define any units but is part of a package that includes a complete implementation of the standard metric system of units and many common non-metric units. The scalar package also allows the user to define a specialized or reduced set of physical units for any particular application or domain. Once an application has been developed and tested, the Scalar class can be switched off at compile time to achieve the execution efficiency of operations on basic numeric types, which are an order of magnitude faster. The scalar class can also be used for discrete units to enforce type checking of integer counts, thereby enhancing the static type checking of Scala with additional dynamic type checking.

share|improve this answer
Looks nice, but dynamic checking is not really one you would want. –  Raphael Feb 17 '11 at 21:11
Yeah, ATC software with run-time type checking? I can see headlines now: "Flight 34 Brought Down By Meter/Yard Conversion"... –  Malvolio Feb 17 '11 at 22:51
Yeah, ATC software with run-time type checking? I can see headlines now: "Flight 34 Brought Down By Meter/Yard Conversion". –  Russ P. Feb 18 '11 at 17:19

Your Answer


