C++ Logo

std-proposals

Advanced search

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

From: Mateusz Pusz <mateusz.pusz_at_[hidden]>
Date: Wed, 19 Jun 2024 09:25:20 +0200
But I meant energy in J, not power. Sorry

śr., 19 cze 2024 o 09:23 Mateusz Pusz <mateusz.pusz_at_[hidden]> napisał(a):

> Both a moment of force and torque are examples here as defined by ISO
> 80000:
>
> [image: image.png]
>
> 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]> 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]> *On
>> Behalf Of *Mateusz Pusz via Std-Proposals
>> *Sent:* Wednesday, June 19, 2024 08:51
>> *To:* std-proposals_at_[hidden]
>> *Cc:* Mateusz Pusz <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]> 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 - 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 07:25:36