Any RFC for Units of Measure?

[newpavlov]

Hm, interesting idea, but I am not sure how Div and Mul implementations for UnitSystem should look with this modification and how generic implementations for UnitValue should be changed. For example what should happen if I’ll divide 10 m^2 by 3 mm/s? Should result be m*s or mm*s? How conversion and loss of precision should be handled if Value=u32? And other similar questions.

Probably we can handle it by making exponents const argument for generic SI type… And thus we will allow creation of derivative unit systems, but not an implicit auto-conversion between them.

[madmalik]

For example what should happen if I’ll divide 10 m^2 by 3 mm/s?

I would say:

10m^2 / (3mm/s)
=  (10u32 [10^0, m^2, s^0] ) / (3u32 [10^-3, m^1, s^-1])
= (10u32 / 3u32 ) [10^(0 - (-3)), m^(2-1), s^(0 - (-1))]
= (10u32 / 3u32 ) [10^3, m^1, s^1]
= 3 kms

… whatever a kms is ;).

[newpavlov]

Ah, so you want to keep an exponent for the whole unit, not for separate dimensions. Hm, I guess it could work, but there is still difficult questions about precision loss and handling of different float and integer types. For example what should happen here 10u32[m] + 1u32[mm]? How to handle computation of 10^n for both floats, integers and maybe arbitrary bigint types? (and don’t forget about overflows) Also your modification will not work with non-SI prefix derivatives. For example what if for astronomy application I want distances in au or light years and leave everything else as-is?

Also for some applications it can be important to keep mm, without implicit conversion to km or something compound.

[madmalik]

Ok, lets think this through

there is still difficult questions about precision loss and handling of different float and integer types.

For me, this would be the most unsurprising behavior. In rust, 10u32/3u32 is 3u32, so having 10u32 [some unit] / 3u32 [some unit] be 3u32 [some unit]would be consistent and logical.

How to handle computation of 10^n for both floats, integers and maybe arbitrary bigint types?

For the pure unit computation, it wouldn’t matter, since the actual values wouldn’t be touched by the units.

Where it starts to matter is convertion between dimensions. That would be number type specific. I don’t know if its possible to abstract that completely, maybe we need number type specific constants for that. Example:

let converter = 1f64/1000f64 kilo;
let x = 4f64 m;
let y = x * converter; // is 4000 mm now

For example what should happen here 10u32[m] + 1u32[mm]

would be a compile time error. [10^0, m^1] is a different unit than [10^-3, m^1]. You’d have to manually convert one of the values so that the dimension line up. At that point, you change of of the values and take the decision what to preserve, range or precision.

Also your modification will not work with non-SI prefix derivatives.

That is correct. Non consistent unit systems are hard. Personally, i would treat it the same way like wie treat unicode. Have an consistent internal representation and convert at the borders. But i get that may be not satisfying.

Also for some applications it can be important to keep mm, without implicit conversion to km or something compound.

If you have a consistent usage of mm, mm/s, mm/s^2 etc. i cannot imagine a situation where one ends up with km somewhere. You’d have to concisely divide by a nonsensical unit to do that.

If that should happen, the compiler would error out because all function in such a system would specify usage of mm and there would be no auto conversion from km to mm.

[newpavlov]

Where it starts to matter is convertion between dimensions. That would be number type specific. I don’t know if its possible to abstract that completely, maybe we need number type specific constants for that.

Yeah, conversion framework will require some design work. At the very least we will need a generic way to calculate 10^n. The most straightforward approach will be to simply loop n.abs() times and do division/multiplication by 10 depending on the sign.

[10^0, m^1] is a different unit than [10^-3, m^1]

Ah, indeed. But it will lead to somewhat surprising interactions, as km/s will be equivalent to m/ms. Though it’s perfectly sound.

That is correct. Non consistent unit systems are hard. Personally, i would treat it the same way like wie treat unicode. Have an consistent internal representation and convert at the borders.

It’s probably will be the most practical solution. Especially if we’ll consider Celsius and Fahrenheit degrees…

If you have a consistent usage of mm, mm/s, mm/s^2 etc. i cannot imagine a situation where one ends up with km somewhere. You’d have to concisely divide by a nonsensical unit to do that.

I’ve meant that you may want to keep 1/(mm^2) instead of converting it to M(1/m^2). But I guess it’s matter of internal representation and shouldn’t matter to users much, and they should do necessary conversion on output/printing stages.

So overall, I think your idea will be indeed a great addition to the proposed system.

[madmalik]

Yeah, conversion framework will require some design work. At the very least we will need a generic way to calculate 10^n .

I could imagine a trait that one has to implement for a number type to be scalable by si dimensions (that trait could be as simple as a single function that gives back the constant 10, together with the Mul and Div traits, we have everything we need). Ideally, that would be the only “touching point” between number types and their units.

I’ve meant that you may want to keep 1/mm instead of converting it to k(1/m). But I guess it’s matter of internal representation and shouldn’t matter to users much.

I haven’t thought about that… yeah, either always show a canonical form when displaying units or have some clever idea to specify the format…

So overall, I think your idea will be indeed a great addition to the proposed system.

Thank you

[gnzlbg]

Probably we can handle it by making exponents const argument for generic SI type… And thus we will allow creation of derivative unit systems, but not an implicit auto-conversion between them.

So that’s what I had in mind.

if I’ll divide 10 m^2 by 3 mm/s? Should result be ms or mms?

When there is no good solution for all cases, I tend to prefer to make things a type error, and ask the user to disambiguate. Here the user would need to explicitly convert either the m^2 to mm^2 or the mm to m before performing the division.

How conversion and loss of precision should be handled if Value=u32 ?

If both quantities use an u32 division should work just like it does for u32s, and conversions should work explicitly in the same way as for other types (e.g. via From when they are “value preserving”).

That is, if one tries to convert 1_u32 mm to u32 m, I expect the result to be 0_u32 m. As mentioned above, I don’t think these conversions should happen implicitly, not even for floats, so I don’t think u32s should be handled any differently.

Implementation wise, the From/TryFrom/… impls have some freedom about how to perform the conversions. For example, when converting from 1_f32 mm to 0.001_f64 m we can apply an f32 unit conversion to the f32 and then convert the representation to f64, or convert the representation first to f64 and then apply an f64 conversion factor. I think this is going too much into the details at this point.

[varkor]

I don’t think thats a problem. The last time a SI unit was added was 47 years ago. Imo its fair that adding or changing base units is a breaking change.

Yeah, that’s reasonable for SI units in particular, but it also seems reasonable that there could be other unit types (probably including user-defined units), which could hit these problems.

[scottmcm]

But if in 1m + 1inch both 1m and 1inch produce value in meters (i.e. they are custom literals which resolve to meters at compile time)

I think it’s important that 1inch produces something that’s repr(transparent) as 1, so that people can use cgs, mks, fps, or whatever without introducing additional conversions or potential precision loss.

To me it’s like forbidding this snippet:

// Nanometer and Kilometer implement From for each other
let x: Nanometer = Nanometer(1.0f32);
let y: Kilometer = Kilometer(1.0f32);
// forbidden. you must explicitly use `into()` to do chosen conversion
let z = x + y;

Note that .into() doesn’t work for that, the same as it doesn’t work for 1_i32 + 1_i8.into().

Supposing that these are stored as f32? as f64? as integers? What about 56e200km+23e-100nm ? Would that be lossless or lossy? How would we detect this at runtime, e.g., for a fn foo(x: km, y: nm) -> km { x + y }?

Probably the same way we detect 5.6e200 + 2.3e-100 at runtime. (AKA we don’t, and that’s fine.)

Yeah, that’s reasonable for SI units in particular, but it also seems reasonable that there could be other unit types (probably including user-defined units), which could hit these problems.

Have any examples? The seven SI base dimensions (mass, length, time, temperature, current, light, amount) seem pretty extensive.

Your proposed system could have another (10-based) exponent for dimension. For meter it would be 0, for millimeter -3 etc. That would also make for a more systematic conversion between dimensions.

I prefer C++'s ratio method for this: a compile-time rational number. That way you can use non-SI units with exact definitions in terms of SI as part of a compatible system, like making the inch exactly 127/5000 of a metre.

[varkor]

Have any examples? The seven SI base dimensions (mass, length, time, temperature, current, light, amount) seem pretty extensive.

Any time you’re working with quantities of objects, you’re essentially using the object as a unit itself. You can create wrapper types over integers, etc., but this requires delegating to the inner value (manually or otherwise). Also, it gets awkward when you want ratios.

More generally, there are a number of non-SI units that are commonly used in practice. It’s plausible you could define these as some sort of alias, but you run into the same sort of precision issues as raised throughout this thread.

[newpavlov]

I think it’s important that 1inch produces something that’s repr(transparent) as 1 , so that people can use cgs , mks , fps , or whatever without introducing additional conversions or potential precision loss.

If we are talking about custom literals it will be up to the crate which defines inch. I don’t think it’s reasonable to require that custom literal always must be transparent, e.g. I want 1minute to be converted to Duration::new(3600, 0) and not to some Minute(1) type.

Note that .into() doesn’t work for that, the same as it doesn’t work for 1_i32 + 1_i8.into() .

Yes, in this particular case youll need to use explicit i32::from, but the main idea still stands.

Probably the same way we detect 5.6e200 + 2.3e-100 at runtime. (AKA we don’t, and that’s fine.)

You assume that we always store unit values as float of the same size, but as was written we may want to store the same unit (Meter) in different “storages”: u32, i64, f32, f64, bigints, etc…

[gnzlbg]

Probably the same way we detect 5.6e200 + 2.3e-100 at runtime. (AKA we don’t, and that’s fine.)

Those two numbers have the same type (either f32s or f64s) but km and nm have different types, and I don’t think that’s fine. I can be convinced otherwise, but avoiding these types of bugs is kind of the point of strongly typing units of measure. If someone wants to get this behavior, they can store both units as m. @newpavlov mentions that people might want to use different reprs types here for storing the types, but I think we won’t want this even if both are stored using the same repr type.

I prefer C++'s ratio method for this: a compile-time rational number

I prefer this as well. We have discussed using something like this in some future version of the chrono crate to deal with time, but without const generics this is really hard to do. It would be great to have a good compile-time rational number library that’s as easy and ergonomic to use as C++ <ratio>. That would be a widely useful thing. Until we get const generics, it’s hard to tell how feasible this is.

[madmalik]

Any time you’re working with quantities of objects, you’re essentially using the object as a unit itself. You can create wrapper types over integers, etc., but this requires delegating to the inner value (manually or otherwise).

I don’t have a solution for this, just a few thoughts.

A lot of these units have domain specific definitions and rules. For example: Currencies have non-const interchange factors, rounding rules and requirements for the underlying data store, Units of time beside SI-derived ones can have very complicated and changing rules (think of leap seconds). It may be possible to integrate all of this into one system, but my intuition is thats its more trouble than its worth.

SI plus some tools to convert other measurements to SI just gives a lot of bang for the buck. When its ok for all of physics, maybe its enough for us too.

[canndrew]

If I’m not misunderstanding something, this approach would make every expansion of the set of base dimensions (for any “unit” type) a breaking change, without a language feature like variadic generics, which seems like a show-stopper.

Not if we use a HashMap for Unit:

struct Unit {
    dims: HashMap<u64, i32>,
}

const fn make_key(module_path: &str, name: &str) -> u64 {
    let mut hasher = Hasher::new()
    hasher.input(module_path);
    hasher.input(name);
    hasher.output()
}

macro_rules! define_unit(
    ($name:ident) => {
        const $name: Unit = Unit {
            dims: hash_map! { make_key(module_path!(), stringify!($name)) => 1 },
        };
    }
)

struct Measure<const U: Unit> {
    val: f64,
}

Then anyone can create and use their own units.

define_unit!(FUNKY);
define_unit!(CHUNKY);

let x: Measure<FUNKY> = ...;
let y: Measure<CHUNKY> = ...;
let z: Measure<CHUNKY * FUNKY> = x * y;

[canndrew]

Of course the “true” way to represents units would be for rust to have existential consts and the ability to reason algebraically at compile-time. eg.

existential const METRE: f64;

let mean: f64 = 2 * METRE;
let std_dev: f64 = 9 * METRE;
let sample: f64 = rand::distributions::Normal(mean, variance);
println!("sampled {} metres", sample / METRE);

This is assuming the compiler had the ability to check that every usage of METRE ends up cancelling-out and so it never has to be given a specific value. I can’t imagine rust ever supporting this, but it’s sort-of doable in languages like Idris.

[madmalik]

One thought orthogonal to the current discussion:

When its (currently) not possible to create a compile time system which is sufficient, what about a runtime system with checks disabled in release builds?

Its a little bit defeatist, but at least it would be possible to to hash out the ergonomics and guide the language design to make it possible at compile time. Also, the error (or in that case, panic) messages could be a lot nicer.

[varkor]

Of course the “true” way to represents units would be for rust to have existential consts and the ability to reason algebraically at compile-time.

I don’t think you can really talk about truth in this sort of situation, but for the actual use-case of units of measure in a type system — dimensional analysis — this approach doesn’t make sense. If you were programming in a dependently-typed language, you would likely use quotient types or setoids (in a manner similar to the canonicalisation).

When its (currently) not possible to create a compile time system which is sufficient, what about a runtime system with checks disabled in release builds?

This would be possible to do entirely in a library (though it does seem like it loses most of the benefits if you only check at run-time), so I don’t think we’d want to consider a run-time solution for Rust itself.

[madmalik]

This would be possible to do entirely in a library (though it does seem like it loses most of the benefits if you only check at run-time), so I don’t think we’d want to consider a run-time solution for Rust itself.

Sorry for being unclear, i was not proposing a build in solution for rust. And i don’t even think such a library would be a real solution to the problem, just a vehicle to explore the ergonomics.

[madmalik]

At least i’m getting a little lost in the weeds on this topic, so i’m trying to summarize and systemize the current state.

So this are the discussed options:

Exponents of a fixed set of base units

The type of the unit is a list of type level exponents of a defined set of base units. Say, all SI units.

What we need:

• type level integers. Since exponents tend to be small, we might get away without them.

Pro:

• Is the most realistic compile time solution with current/near future rust.
• Simple to implement

Cons:

• Limited. Unit systems are closed and can’t be extended by users and by the library author only with a breaking change
• Type errors border on unacceptable. For example, m/s^2 would be something like

SI {
    meter: 1,
    second: -2,
    kelvin: 0,
    kg: 0,
    mol: 0,
    candela: 0,
    ampere: 0
}

and that is with native type level integers.

Variadic set of base units with type level exponents or multiset of base types for nominator/denomitator

The design space is quite wide for such a solution, because of that i don’t try to summarize it in one sentence. More or less a stand in for the type theorist wet dream solution.

What we need:

• a much more powerful type system. Beside type level integers we need either type level sets/multisets or variadic lists and unification.
• probably custom type error messages.

Pro:

• actually what most of us want

Contra:

• I won’t hold my breath that the required features actually land in rust in the foreseeable future.

Compiler magic

Aka the F# solution. Bake in unit unification into typechecking as a special case.

What we need

• nothing in particular, since it would be tailored to our needs

Pro

• most potential in terms of ergonomics

Contra:

• High cost in terms of compiler maintenance and language complexity
• There is (rightly so) quite a bit of resistance against compiler magic
• Bikesheding potential is high, so even if the community went along with compiler magic, it’d be hard to iterate a solution without the typical “external library goes to nursery goes to std lib” path since there are so much design parameters

library solution with runtime checking

Aka giving up. There is as much design space to explore as with compile time solutions, but since it played little part in this discussion, i summarize it as one point.

Pros:

• Actually possible with current rust
• There is a lot of precedence in other languages

Contra:

• Not zero overhead
• Even if we find that most use cases would be fine with the overhead, it goes very much against the idea of rust.

I don’t think this would be a good solution overall, but there are two reasons why i don’t want to discard it completly

1. there are actually legitimate use cases for run time unit checking. If we build a library that can do compile time checking, maybe it should also be possible to defer it to runtime
2. it could be a good way to hash out the ergonomics.

other stuff

Speaking of ergonomics… imo that topic should play a bigger part in this discussion. Everything that makes it harder to use units will result in people not using them. Also, our minimum bar on type errors should be something like: “expected unit of meassure m/s, but found kg” or something like that, not a printout of the necronomicon like we get with type trickery a’la typenum.

[canndrew]

Variadic set of base units with type level exponents or multiset of base types for nominator/denomitator

…

• I won’t hold my breath that the required features actually land in rust in the foreseeable future.

All we would need is const generics, which should land within the next year (or maybe sooner if we all cheer @varkor on). Ideally we would also want the ability for const functions to allocate, but until then we could just have a hard limit on the number of units people can define and make the hash map (or whatever) fixed-size and unboxed.