Hacker News Reader

Comment by loeg | Hacker News Reader

The author didn't mention this, but maybe there could be a type (unit) canonicalization step that always produces the same reduced/simplified type for any equivalent set of Mul/Divs? So that you don't need the later equivalency check.

E.g. with the article's example, where 'a' is Meters and 'b' is Seconds, 'a/(b*b)' and 'a/b/b' both have type 'Div<Meters, Mul<Seconds, Seconds>>' instead of one having the type 'Div<Div<Meters, Seconds>, Seconds>'.

For only Muls and Divs you can basically just have a histogram of units to powers (e.g., m/s^2 => m: 1, s: -2) which uniquely represent equivalent types.

View on HN

James Gosling looked at this and wrote about it at the time. It can be a bit mind bending. Especially with units named after people.

If you’re looking at statistics for current or power the type system might try to convert it to joules even though you wanted to look at average wattage.

Yeah, but equivalent units with different names is sort of only a display/formatting issue, right?

This is a matter of perspective.

For example the unit Sievert is an official SI unit despite being just J/kg. This is because confusing equivalent dose and absorbed dose, which also has the unit of J/kg, could be very dangerous.

Note, that this is different from J sometimes being written as Ws. While there are informal conventions, when we use J and when Ws, using the unconventional one would not be technically wrong because 1 J is simply 1 Ws, whereas 1 Sv is not necessarily 1 J/kg when the later is an absorbed dose.

I think one could reasonably disagree with these decisions but that is how the SI people see it.

> This is a matter of perspective.

I'd make a stronger statement here; this is a specific example of when having units is most powerful. When even though two things are expressed in some common form, they nevertheless represent something different.

> Yeah, but equivalent units with different names is sort of only a display/formatting issue, right?

This could be said of two u32s as well.

> When even though two things are expressed in some common form, they nevertheless represent something different.

This is where people go wrong trying to DRY and other refactors. Slightly forced example but

  function averagePerClassroom(total) { return total / 30; } // 30 kids per class
  function averagePerMonth(total) { return total / 30; }  // assume 30

"Oh, the function body is the same therefore lets refactor this into an "averagePer" function" expect its two completely different concepts and once the code calculates the actual days per month or once classes are no longer 30 people suddenly things need to be un-refactored, or what I see more often, is just branching off inside the new single function based on an argument flag. Horrible.

Sievert is more of a "newtype" in Rust/Haskell terminology than a separate unit. Likewise for radians and moles.

Torque is actually J/rad.

Not in freedom units.

Sure, but I think this is still better than declaring type system bankruptcy because determining whether trees of units are equivalent is hard. You could do newtype wrappers in situations where it is warranted.

A joule, notably, is a newton-meter. Torque is also measured in newton-meters, but the meters are perpendicular to the newtons.

Adding energy to torque is rarely going to be intentional.

I do not understand, average wattage/power would be integration of wattage (joules) divided by time (so back to watts), it’s still watts? Under what implementation would you end up with joules that isn’t just oddly broken in general?

I guess I could see a naive implementation (confusing integration/sampling and discrete summation) going the other way, erroneously ending up with a nonsensical W/s.

Also don’t understand what it has to do with eponyms, which are just substitutes for base units, either your DA works or not, no? Average wattage is kg⋅m²⋅s⁻³ not kg⋅m²⋅s⁻² (joules) or kg⋅m²⋅s⁻⁴

> I do not understand, average wattage/power would be integration of wattage (joules) divided by time (so back to watts), it’s still watts?

Average wattage is measured in watts. You compute it by integrating and then dividing by the measure of the domain of integration.

I used javax.measure a few years ago on a project that was about building a material search engine. It featured search by all sorts of chemical and physical properties. Complete with all the wonderful units that are used around the globe to measure tensile strength, breaking point, conductivity, magnetic properties, etc. To avoid comparing apples to oranges when searching, being able to normalize and convert between different units is key. Additionally, allowing to user to search with their preferred units is also important. We supported hundreds of different properties for a wide range of ceramics, metal alloys and other materials.

Not the easiest framework to work with but pretty well thought out. A good starting point if you are looking to reinvent that wheel.

A simple way to do this is to store a vector of the powers.

For example momentum is kilogram * meter / second, which is MASS^1 * LENGTH^1 * TIME^-1

As a vector, this can be represented as (1,1,-1) where the positions are M, L, T respectively.

In that format velocity is represented as (0,1,-1), acceleration is (0,1,-2), etc...

This is automatically canonicalised and much easier to manipulate than a tree of operations.

Of course, this assumes uniform units such as CGS or MKS in something sane like the metric system. Conversion back and forth is generally straightforward, as long as the types encode the system used. E.g.: CGS<1,1,-1> and MKS<1,1,-1> both represent momentum, but at different scales.

Imperial also works, and other base units can be added to extend the system. This can include things like current, temperature, moles, etc...

See: https://en.wikipedia.org/wiki/Dimensional_analysis

> This is automatically canonicalised and much easier to manipulate than a tree of operations.

As long as the vector is sorted by unit, yeah. With that caveat, it's the same idea.

It’s a positional system with the same basic measurement units always at the same index locations.

there are 7 si units, and you can represent all the powers you need in 8 bits, so you can pack every reasonable SI unit in 64 bits

The author did mention this. It's exactly what the F# article they cite is about:

http://typesatwork.imm.dtu.dk/material/TaW_Paper_TypesAtWork...

I believe you that the F# PDF describes it, but the text of the fine article itself does not describe it in any recognizable way.

Reply on news.ycombinator.com