Any RFC for Units of Measure?

[Yoric]

while Boost handles this with non-compositional magic numbers

Which ones?

If I read Boost correctly, these ones.

Looks good! It would be cool if the user-guide section would show, for example, how to implement “mini” SI and CGS systems of units that include length, time, and velocity. Then show how to specify the conversions between the natural units of those systems, and finally how to convert between velocity in CGS and velocity in SI, for example, m/s to mile/h, or km/h to inches/s.

Good idea.

[gnzlbg]

If I read Boost correctly, these ones.

Which constants are there ? That page just explains dimensional analysis.

[jmst]

Isn’t it enough to introduce “where T < U”, “where T <= U” and “where T == U” bounds where T < U is an arbitrary total order on types? (and at least compatible with in-crate declaration or lexicographic order, so units come out in consistent order)

Along with specialization and a smart enough trait resolution system (esp. one that knows that T < U || T == U || T > U), that should allow to define everything else as a library while retaining full composability.

Or equivalently, add negative where bounds, “where T == U”, and a “TypeLess<T> : U” compiler-provided trait.

[Yoric]

Which constants are there ? That page just explains dimensional analysis.

The long N template argument on that page.

[Yoric]

An arbitrary total order on types is necessary and a bit tricky to get right – how do you order type variables?.

I don’t think it is sufficient, as you also need to be able to factor in the fact that A/A == 1. I’d be happy to be proven wrong, though.

Finally, you need to handle the problem of keeping syntax and error messages readable, but I believe most of it can be done as syntactic sugar.

[H2CO3]

This looks, smells and sounds like something that really-really-really shouldn’t be baked into the language. Typesafe units are nice and probably pretty much necessary for any reasonable numeric/engineering/physics/simulation work that claims to be safe or correct by design. However, they are so fundamentally type-related and well-described by types that before (and ideally, instead) of adding them as magic special cases to the language, we should really strive for making the type system more powerful in general and try to express them in terms of more fundamental features of the type system. In the wider perspective, adding even more built-in traits isn’t much better than requiring globally unique magic constants. While it is of course significantly less fragile, it still doesn’t feel more principled and general at all.

So instead of rushing to an RFC that extends the magic part of the language (of which we already have way more than what would be justified in a language that wants to solve C++'s bloat/complexity issue…) even more, I suggest that we consider instead what kind of expressiveness/additional power the type system needs, and try to achieve those goals in a less coupled, less units-specific manner instead. That would also mean that more potential users could benefit from them.

[Yoric]

I suggest that we consider instead what kind of expressiveness/additional power the type system needs, and try to achieve those goals in a less coupled, less units-specific manner instead. That would also mean that more potential users could benefit from them.

Of course. I just want to start the conversation somewhere. I’ll try and post an updated draft tomorrow, feel free to make holes in it if you realize that something smaller would work.

[gnzlbg]

The long N template argument on that page.

long N template parameters are generic type-level consts. In which way are they “non-compositional magic global values”?

[Yoric]

With this, we can define the base dimensions for length, mass, and time as:

/// base dimension of length
struct length_base_dimension : base_dimension<length_base_dimension,1> { };
/// base dimension of mass
struct mass_base_dimension : base_dimension<mass_base_dimension,2> { };
/// base dimension of time
struct time_base_dimension : base_dimension<time_base_dimension,3> { };

It is important to note that the choice of order is completely arbitrary as long as each tag has a unique enumerable value; non-unique ordinals are flagged as errors at compile-time.

(emphasis added)

[gnzlbg]

Ah, I see what you mean now.

Note that these tags types are only a convenience. Units are type lists of base dimensions, and being able to sort these type lists allows to always reduce composite units to the same unit type which is some sort of unification. The only thing required for sorting is for the base units to have a total order - the concrete order is irrelevant.

Without sorting capabilities, one expression might produce kg * m * s and a different expression might produce m * kg * s. Because the base units are in a different order, these expressions have different types and would not unify. If you had a total order and a way to sort according to it every time a composite expression is produced, one could always produce consistent types that unify.

Assigning each base unit a unique integer is just one of the many ways there are to give a sequence of types a total order.

[Tom-Phinney]

Assigning each base unit a unique integer is just one of the many ways there are to give a sequence of types a total order.

But it does provide a total ordering that is sharable between different systems of units, such as between SI and CGS. Lexicographic ordering of the base units within each system, for instance, would not provide that.

[Yoric]

Without sorting capabilities, one expression might produce kg * m * s and a different expression might produce m * kg * s. Because the base units are in a different order, these expressions have different types and would not unify. If you had a total order and a way to sort according to it every time a composite expression is produced, one could always produce consistent types that unify.

Exactly.

Assigning each base unit a unique integer is just one of the many ways there are to give a sequence of types a total order.

Sure, but it’s non-compositional

[Yoric]

Updated the pre-pre-pre draft. I have made some efforts to try and separate goals, but it’s not there yet. Any suggestion welcome!

[gnzlbg]

But it does provide a total ordering that is sharable between different systems of units, such as between SI and CGS. Lexicographic ordering of the base units within each system, for instance, would not provide that.

Indeed. A total ordering shareable between different systems of units can be convenient for the implementation, depending on how convenient the units library wants to be with respect to conversions, but it is not necessary.

@Yoric

Sure, but it’s non-compositional

What’s non-compositional? Having a total order on base dimensions? Using unique integers to do that?

[Yoric]

Well, you need magic numbers that are unique across your entire application. So if you have two libraries and they collide by using the same magic number, it’s game over.

Indeed. A total ordering shareable between different systems of units can be convenient for the implementation, depending on how convenient the units library wants to be with respect to conversions, but it is not necessary.

Looks to me like without these numbers, s*m/s != m, which is a pretty big deal.

[gnzlbg]

Well, you need magic numbers that are unique across your entire application

You just agreed that you don’t need magic numbers to give types in a type list a total order so I don’t know why you keep re-stating that magic numbers are required. What did I miss?

For example, an alternative to magic numbers would be to just use a type predicate to specify the total order (e.g. Less<A,B>::Bool). IMO the focus here should be on how specifying a total order affects composability.

Looks to me like without these numbers, s*m/s != m, which is a pretty big deal.

That’s equivalent to simplifying Mul< Mul< T<1>, L<1> >, T<-1> > down to L<1>. While sorting types can be helpful, I don’t see how sorting, and therefore, a total order, is necessary to perform these simplifications. Sorting might help on reducing the algorithmic complexity or improving the efficiency of the simplification, but that’s about it. What am I missing?

[Yoric]

What am I missing?

Well, maybe I’m the one missing something, but I had the impression that these numbers were key to deciding equality between types. The alternative being manually specifying something like your Less<A, B>::Bool, which doesn’t really scale up, either.

[JoeyAcc]

I’ve been working on a (yet-unpublished) crate called sigh (as in SI pronounced as a word). It does more or less what you propose at the type level, and also accounts for SI prefixes. For example, it’s possible to add X cm to Y m and get the correct result. What it can’t do yet is composite units (i.e. m/s, mAh etc), as I haven’t quite figured out how to do that yet.

If anyone is interested, I could open up and publish the (unfinished!) code to make room for collaboration. The main reason I haven’t done so yet is because the project is not finished.

[gnzlbg]

I think it’s better to treat the two issues as separate. It would be first worth answering (in the prior art section after discussing a bit what Boost.Units does) whether we need a total order between units for something at all. What would that buy us? What does that buy Boost.Units? Does this total order need to be global (which as you say won’t scale) to buy us something, or is it enough for it to be system local? And finally, depending on what it buys us, and how much it costs, then explain the rationale of whether we want it or not and why.

I think that independently of the implementation chosen, if we need a total order, and this order must be global to be useful, then that’s bad news. Adding a new base unit would mean having to specify its order with respect to the system somehow, but crates do not know about the base units specified by other crates, so I really don’t know how such a global total order could be implemented in a way that scales.

As to the specific way in which one can implement total ordering of base units, I’d say it would be better to just ignore the specific implementations until the other questions are properly resolved. I’ll read the F# unit publications these days, since maybe the questions I am posing are dumb if one has read those (but the RFC should not assume that everybody has).

[Yoric]

The part I’m interested in is composing units, so I think that this is either orthogonal or complementary