Lambda the Ultimate

Though I haven't tried it out, this implementation seems to suffer from the same problem as must "syntactic" units packages since time immemorial. It assumes that because energy and torque have the same units (kg m^2 / s^2) that they are interchangeable. Alas, they are not, because energy is a scalar, torque a vector. Likewise, at a higher level of abstraction, length, width, and height are all measured in meters, but though multiplying them is sensible, adding them is not. Temperatures can be subtracted but not added. And so on.

Creating a units system that can be made to understand all these things is a huge effort, and one that as far as I know has never been done. Still, 0.5 loaf is much better than no bread.

While Mark's past contributions to LtU are appreciated, for future reference, it's not appropriate for a contributing editor to post his own projects to the front page unless invited to do so, as in the case of guest bloggers. Instead, we encourage such entries to be posted as a forum topic, with a clear statement of the poster's own connection to the project.

johnwcowan

Units have subtle issues. Influence by example means handling some in shipping code. I'll check off your list to motivate interest.

There is no syntactic orientation. DsU separates presentation from semantics. A whole machinery serves the purpose. Maybe I miss your meaning.

DsU handles torque vs. energy. Read the backgrounder. The force catalog has a footnote. They differ by angle.

DsU has extension quantities. These carry identical dimensions as the generic, yet remain distinct. Example: volume_beverage extends volume. The notion permits discrimination, where useful, on a different footing than dimension.

Temperature sums work. The relevant catalog tweaks them. Behavior almost matches your spec. It can change to taste. The code is brief, exploiting hooks for custom algebra.

The length-width-height matter is vector analysis. Units live at a lower level, as you say. The upper level rules are plain old vector algebra, not a unit library's job. Interaction bugs would be implementation, not design boundary flaws. Please read my math comments to Casey McCann, too.

naasking

Is something in F# worth comparison or contrast?

Microsoft and Sun have seen my site. Microsoft visits with some regularity. I'm glad to help designers. I'd love to hear from them, even do work. Wolfram Research called with great interest.

Casey McCann

Our ideas seem close. Units as math aren't consistent.

Offset is fundamental. What are called "functional" quantities handle it. The label means they need functions more complicated than a multiply.

Decibels work. The validation suite shows corner cases and varying "meaning[s] of addition" for dB. It ships in the software. The backgrounder touches dB. Weighted flavors like audio need attention.

Interaction between scales and units has puzzles, perhaps. Units make enough work.

The word "underspecified" is mostly math lingo. What it suggests is better guidance outside math, not lost hope. Escape is everything. Guy Steele said units form a group. Only a subset can, if large. General units form a small language with odd rules. Smallness fuels hope. The language outlook drives units in Wolfram|Alpha. And they're a math company...

One veers off the rails conflating math ontologies with units. Points, vectors, scalars, torsors!, lines, origins, frames, distances, groups, and the rest form extensive families. Units aren't relations, just nice neighbors. Call them a language and you're finished with math metaphors.

User burden statements lost me. Encoding helps; that's the point. I want to write units as on paper. The computer should figure things out from its rule base.