Date: Tue, 18 Jun 2024 21:30:22 -0400

On Tue, Jun 18, 2024 at 9:03 PM Thiago Macieira via Std-Proposals <

std-proposals_at_[hidden]> wrote:

> 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_at_[hidden]

> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

>

std-proposals_at_[hidden]> wrote:

> 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_at_[hidden]

> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

>

Received on 2024-06-19 01:30:35