Date: Wed, 19 Jun 2024 09:23:45 +0200
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
>
>
[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:24:02