On Tuesday 18 June 2024 10:06:09 GMT-7 Charles R Hogg via Std-Proposals wrote:
> A basic design principle for a units library is that the result of a
> computation shouldn't conjure up any units not mentioned in the inputs.
Why not? If I multiply an acceleration by mass, why should I not get newtons?
If I divide a charge by time, should I not get amperes?
Thanks for asking! Here's what I meant, in more detail.
If you multiply an acceleration (m / s^2) by a mass (kg), the units of this intermediate computation result should be (kg * m / s^2). If you print it out, the unit label should be this (or something equivalent). Perfectly correct, perfectly consistent with the basic rules of quantity calculus. No surprises.
If you then try to assign this result to a quantity of newtons (N), it should be implicitly convertible. It has the same dimension, and same magnitude, so the library should permit this as a direct assignment, with no runtime conversion factor. So, for intermediate computations, just use whatever unit falls out naturally, and for assignment, check the dimension and magnitude to see whether it's permitted.
(Aside: mp-units also supports more sophisticated reasoning, whereby we can distinguish between different kinds-of-quantity that have the same dimension and magnitude, but I wanted to keep it simple for this example. That, and if I don't mention this, then Mateusz will jump in and correct me. :)
Now, if you wanted the result of an acceleration times a mass to simply already be in Newtons, you could make that work, but at a cost. You would have to introduce the notion of a globally "preferred" unit for each (dimension, magnitude) combination. Adding global registries to the library would increase complexity and fragility, and make the library harder to reason about. mp-units abandoned this approach pre-2.0 and has never looked back.
PS: would this proposed API support a unit like ns/√km ?
Yep!
Cheers,
Chip
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Principal Engineer - Intel DCAI Fleet Systems Engineering
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals