Unit spec: CLDR, UCOM, or something else?

[sffc]

Unicode CLDR gives a list of units: https://github.com/unicode-org/cldr/blob/main/common/supplemental/units.xml

There is also another list of units in a standard called The Unified Code for Units of Measure published by the Regenstrief Institute, which appears to be associated with Indiana University. https://ucum.org/ucum

Of course there is SI itself, published by the BIPM. https://www.bipm.org/en/

@zbraniecki has pointed to the Rust crate uom which implements the international system of measurements. It's not clear to me where exactly the crate gets its list. https://docs.rs/uom/0.36.0/uom/si/length/index.html

These different lists have different features and were made for different use cases. Unicode CLDR is primarily oriented toward units for human display; it is nominally what we use in ECMA-402 (although ECMA-402 contains only a small subset of it), and one key feature is its support for mixed units such as foot-and-inch. I am not as familiar with the other systems, so I can't speak as well to their advantages and disadvantages.

CC @zbraniecki @macchiati @roozbehp

[ben-allen]

Upon looking through the UCUM list and the NIST's Guide to the SI, it seems like there's several units of more than historical interest that are not present in CLDR. The most immediately notable are the various units derived from the U.S. survey foot and possibly the apothecaries' weight units.

That said, I'd like to echo @sffc on the absolute necessity of support for mixed units, which is a clear advantage for CLDR.

Additionally, it appears that CLDR's support for the Scandinavian mile is an advantage for localization purposes. Cursory research indicates that it is in fact in general conversational usage in Sweden and would be important to support for localization purposes, though I'll have to defer to people with first-hand knowledge of customary units in Sweden on whether my cursory research is accurate.

[eemeli]

My sense is that this is perhaps beyond the scope of this proposal? We already have a list of Single units sanctioned for use in ECMAScript, and that probably ought to match what Measure is expected to support. Extending that list doesn't need to be a part of this work.

One part that we do need for Measure is support for -and- as a unit connector like -per-.

[sffc]

One part that we do need for Measure is support for -and- as a unit connector like -per-.

This is exactly why we need to consider which spec to support. The -and- and -per- thing is very CLDR-specific.

[eemeli]

Given that we already support -per- and explicitly describe the ECMA-402 supported units as "a subset of the Common Locale Data Repository release 38 unit validity data", I would find it quite surprising and needing some strong arguments to choose a different reference for Measure.

[sffc]

Well, we chose the CLDR units previously because we were building a formatting API, and CLDR defines units for formatting. Now we're building a more general-purpose API, so the choices we make might be different.

The fact that we chose a fairly small subset of the CLDR units means that it should make it easier if we wanted to use a different spec for this proposal.

[zbraniecki]

I'd like to better understand the relationship between CLDR and other systems, and have it explicitly documented.

Measurement paradigm in CS is a much needed overhead for a particular class of engineering problems that mostly exist on the boundary between components.
ECMA coming at it from internationalization perspective is imho misplacing the crux. The problem is not how to best display quantities in a given locale, the problem is how to express quantities across composable systems.
Locale formatting of them (including presentation oriented conversions) are imho a far lower order of priority.

If you disagree with me, then I don't think there's much value in debating the solution. CLDR is a manually curated system designed for i18n and CLDR is the right choice.

If you, on the other hand, find your self open to my argument, then CLDR in itself is insufficient. How will you bridge the gap to JSR 385 in Java? UOM in Rust? UOM in C++ (alternative)? UOM in Python? UOM in Swift?

All of the abovementioned APIs are growing to follow SI, ISO 80000 and companies and industries are in a good position to grow interoperability between the systems around the single definition of Measurement, Quantity, Unit (Base and Derived), Dimensions, Coherency, Prefixes, Compound Units, Units Sequences etc.
CLDR introducing "foo-per-bar" proposes an alternative architecture for compound units, and maybe it is algorithmically translatable between CLDR and ISO - I'd like to understand if it is guaranteed to be.
How CLDR handles Metric Prefixes vs ISO? How does does it handle non-coherent units?

Maybe it's ok to say that the translation is guaranteed one way - from ISO to CLDR? "Any ISO 80000 UOM measure can be converted to CLDR"?
But my concern is that we're designing I18n spec that is not composable and interoperable with non-i18n specific UOM that programming languages and introducing.

[sffc]

@zbraniecki I'm still trying to find the list of units that all these libraries accept and how they can interoperate with each other. For example, how do you send "1.5 meters" from C++ UOM to Python UOM?

There's this big module in Rust: https://docs.rs/uom/latest/uom/si/index.html

And there are specific units in Swift: https://developer.apple.com/documentation/foundation/units_and_measurement

But I am having trouble finding any document or data file that specifies what units are allowed and how they serialize. All the specs I find are like, "this is what a unit is, this is what a dimension is" without saying what units and dimensions are allowed. In CLDR, I just look at units.xml.

[zbraniecki]

I'll walk through how I do it, I don't think it's very... friendly. Especially that ISO is not public.

Standards

ISO 80000-1 specifies seven base quantities

In the ISQ , with the seven base quantities length, mass, time, electric current, thermodynamic
temperature, amount of substance and luminous intensit y, the dimensions of the base quantities are
denoted by L, M, T, I, Θ, N and J, respectively. Hence, in the ISQ , the dimension of a quantit y Q in general
becomes
dim Q = L αMβTγIδΘεNζJη

ISO 80000-3 Table 1

Item No. 3.1.1
Quantity
Name: Length
Symbol: l, L
Definition: linear extent in space between any two points
Base unit: meter
Remarks: Length does not need to be measured along a straight line.

IEC (link)

Area Quantities and units / International System of Units
IEV ref 112-02-05
Symbol m
en metre / meter, US
SI unit of length, equal to the length of the path travelled by light in vacuum in a duration of 1/299 792 458 s

Implementation in Rust

Uom has meter unit, which I can use to create a 1.5 meters:

use uom::si::{
  f64::Length,
  length::meter
};

let length = Length::new::<meter>(1.5);

and in Java:

import javax.measure.Quantity;
import javax.measure.Unit;
import javax.measure.quantity.Length;
import tech.units.indriya.quantity.Quantities;
import tech.units.indriya.unit.Units;

Quantity<Length> length = Quantities.getQuantity(1.5, Units.METRE);
double value = length.getValue().doubleValue();
Unit<Length> unit = length.getUnit();

and in Python:

from pint import UnitRegistry
ureg = UnitRegistry()
length = 1.5 * ureg.meter
print(length)

C++ (boost):

#include <boost/units/systems/si/length.hpp>
#include <boost/units/quantity.hpp>

boost::units::quantity<boost::units::si::length> length(1.5 * boost::units::si::meter);

and Swift:

import Foundation

let length = Measurement(value: 1.5, unit: UnitLength.meters)
print(length)

Now, there are many operations I can do on it. (I'll use Rust now):

Conversion

use uom::si::f64::*;
use uom::si::length::{meter, mile};


let length_miles: Length = Length::new::<mile>(1.0);
let length_meters = length_miles.get::<meter>();

Composed units:

let x_feet = 5.0; // Example: 5 feet
let y_inches = 8.0; // Example: 8 inches

let length_feet: Length = Length::new::<foot>(x_feet);
let length_inches: Length = Length::new::<inch>(y_inches);

let total_length = length_feet + length_inches;

println!("Total length in meters: {:.3} m", total_length.get::<meter>());

Combinations

use uom::si::f64::*;
use uom::si::{
  length::{meter, kilometer},
  time::{second, hour},
  velocity::{kilometer_per_hour, meter_per_second},
  mass::kilogram,
  energy::joule
};

fn main() {
    let speed: Velocity = Velocity::new::<kilometer_per_hour>(50.0);
    println!("Speed: {:.3} km/h", speed.get::<kilometer_per_hour>());

    let speed_mps = speed.get::<meter_per_second>();
    println!("Speed in meters per second: {:.3} m/s", speed_mps);

    let mass: Mass = Mass::new::<kilogram>(2.0);
    let length: Length = Length::new::<meter>(3.0);
    let time: Time = Time::new::<second>(2.0);

    // Calculate energy
    let energy: Energy = mass * (length * length) / (time * time);

    println!("Energy: {:.3} J", energy.get::<joule>());
}

More arbitrary:

use uom::si::f64::*;
use uom::si::information::byte;
use uom::si::length::kilometer;

fn main() {
    let data_amount: Information = Information::new::<byte>(1500.0);
    let distance: Length = Length::new::<kilometer>(3.0); // 3 kilometers

    let bytes_per_km = data_amount / distance;

    println!("Data amount: {:.0} B", data_amount.get::<byte>());
    println!("Distance: {:.1} km", distance.get::<kilometer>());
    println!("Bytes per kilometer: {:.3} B/km", bytes_per_km.value);
}

and you can go further defining your own dimensions, units, derived units, conversions etc. I believe every UOM library offers similar functionality based on the same semantics and standards.