C++ Logo

std-proposals

Advanced search

Re: [std-proposals] On the standardization of mp-units P3045R1

From: Tiago Freire <tmiguelf_at_[hidden]>
Date: Wed, 19 Jun 2024 07:25:03 +0000
Yes, and I have also explained to you why.

From: Mateusz Pusz <mateusz.pusz_at_[hidden]>
Sent: Wednesday, June 19, 2024 09:24
To: Tiago Freire <tmiguelf_at_[hidden]>
Cc: std-proposals_at_[hidden]
Subject: Re: [std-proposals] On the standardization of mp-units P3045R1

Both a moment of force and torque are examples here as defined by ISO 80000:

[cid:image001.png_at_[hidden]]

Also, SI clearly states:

For example, the quantity torque is the cross product of a position vector and a force vector.
The SI unit is newton metre. Even though torque has the same dimension as energy (SI unit
joule), the joule is never used for expressing torque.


śr., 19 cze 2024 o 09:15 Tiago Freire <tmiguelf_at_[hidden]<mailto:tmiguelf_at_[hidden]>> napisał(a):
Well, that’s because as you maybe figuring out scientist can be very sloppy with their units.

> Also, power should be measured in `W` but moment of force in `N * m`

You mean Torque. That’s because torque is actually `N * m / rad` and because torque is homeomorphic to 1 it just disappears and becomes `N * m`.
Where you to be rigorous you shouldn’t be able to just puff it out of existence.
My library actually does this to prevent this sort of confusion.

Same thing happens in Bq, there’s are actually supposed and additional unit of something that’s homeomorphic to 1 that just gets blasted out of existence.
It’s an orthogonal problem.


From: Std-Proposals <std-proposals-bounces_at_[hidden]<mailto:std-proposals-bounces_at_[hidden]>> On Behalf Of Mateusz Pusz via Std-Proposals
Sent: Wednesday, June 19, 2024 08:51
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>
Cc: Mateusz Pusz <mateusz.pusz_at_[hidden]<mailto:mateusz.pusz_at_[hidden]>>
Subject: Re: [std-proposals] On the standardization of mp-units P3045R1

This should not happen implicitly in the framework. We had this issue in mp-units V1 where the downcasting framework was doing the automatic conversion for the user. With time and more experience in the domain we found out this to be really wrong.

Hz = Bq = 1 / s

In the V1, `1 / s` always resulted in `Hz`, which made the framework impossible to yield `Bq`. Also, someone implemented an application that counted the number of cars passing a crossroad on the highway. They got results in `Hz`, but they really wanted `1 / s`.
Consider also `Gy` and `Sv` or `rad` and `sr`. Also, power should be measured in `W` but moment of force in `N * m`.

This is why I strongly believe that such conversions should be done explicitly by the user.

śr., 19 cze 2024 o 03:03 Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> napisał(a):
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?

PS: would this proposed API support a unit like ns/√km ?

--
Thiago Macieira - thiago (AT) macieira.info<http://macieira.info> - thiago (AT) kde.org<http://kde.org>
  Principal Engineer - Intel DCAI Fleet Systems Engineering



--
Std-Proposals mailing list
Std-Proposals_at_[hidden]p.org<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

Received on 2024-06-19 07:25:09