I don't know anything about boost.units, but radians are dimensionless.

In Boost.Units, radians are not dimensionless. (This is what allows it to catch user errors such as assigning degrees to radians.) Albert

Hi, Matthias! On 08/26/2022 12:35 PM EDT Family Schabel wrote:

Maybe this link will clarify:

https://physics.stackexchange.com/questions/37881/why-is-torque-not-measured...

There’s also a discussion of this issue in Wikipedia: https://en.wikipedia.org/wiki/Radian

Thank you for your reply and the links, and of course also for your work on Boost.Units, which I find very useful. It's good to know that the current behavior is intentional. I had not previously encountered the idea of expressing torque in N m/rad, so I took a while to think it through. Another summary of the topic that I found helpful was presented in two 2016 papers by Quincey and by Quincey and Brown: https://doi.org/10.1088/0026-1394/53/2/840 https://doi.org/10.1088/0026-1394/53/3/998 I apologize in advance for my terrible math "typesetting." To summarize: Boost.Units treats angles as base quantities, rather than dimensionless, so it can for example distinguish between radians and degrees. Given that, the formula for the work done by a torque on a rotating body W = \integral \vec{\tau} d\vec{\theta} implies that the torque should be expressed in N m/rad. This is not dimensionally compatible with some other formulas for torque, e.g. from applying a force at some distance from an axis of rotation, traditionally written as follows, with torque in N m: \vec{\tau} = \vec{r} \cross \vec{F} Since a units library such as Boost.Units needs to be consistent, it must choose a way to reconcile the two, and can't get away with hand-waving that radians are sometimes a base unit and sometimes just a funny way of spelling a dimensionless constant.

Boost Units explicitly keeps track of angular displacement for this (and similar reasons). The unit of torque really should not be energy (J or N.m) because a torque is a force applied tangentially, so, to compute the amount of energy required to exert a torque one needs to take the product of the force with the angular displacement.

I agree that choosing N m/rad as the units of torque seems reasonable, if non-traditional, and I don't expect to get anyone to change that decision now. (I don't think this was a *necessary* choice, though; using N m would also have been reasonable. I may be biased by the fact that what I usually work with are force-based calculations in static scenarios where there is no angular displacement, and so no work being done.) But the two equations above are still not dimensionally consistent, and as Quincey & Brown point out, to make them consistent you have to change the traditional torque-distance-force equation by adding a dimensionless factor \eta = 1/radian, introduced by Torrens: \vec{\tau} = \eta \vec{r} \cross \vec{F} I think this introduces a documentation problem for Boost.Units. I don't know exactly how many users will be completely blindsided by this, but my team at work and I were definitely included, and I think this situation will be pretty common at least in the US. These users may run into compilation issues they don't understand, view this as a result of some deficiency in Boost.Units, and implement undesirable workarounds (as an example, my team created local specializations of boost::units::multiply_typeof_helper that "made things work"). To avoid this, I think the documentation should describe the choices made by Boost.Units with respect to torque, moment of inertia and angular momentum, and the implications of those choices. If the maintainers agree, I'd be happy to draft some patches for review on Github. It would probably also be beneficial to define \eta = 1/radian for users to use.

The nomenclature is a bit confusing because, as you note, newton_meter is not the same as newton*meter - the convention is that torque is measured in newton meters, but it is really newton meters per radian as encoded in the library.

I'm really perplexed by this statement. The Boost.Units code base supports the general idea that angles should be treated as a base unit. If so, then surely N m/rad and N m are different units! Blurring this difference will increase user confusion about how to correctly use the library. Saying that the units are N m/rad but that we choose to label this newton_meter makes no sense to me. (This gets extra confusing for our code base at work, which includes calculations using torsional stiffness, i.e. torque per unit angular displacement. If boost::units::si::newton_meter is N m/rad, what should we call the unit of torsional stiffness (N m/rad^2 here, but N m/rad "traditionally")? newton_meter_per_radian, for consistency with newton_meter, but really confusing given its actual definition? Or something else, inconsistent with the other units?) The right choice would be to define newton_meter_per_radian as a unit of torque, and in my opinion also to deprecate the existing definition of newton_meter. Thank you, Albert

There’s also a discussion of this issue in Wikipedia: https://en.wikipedia.org/wiki/Radian

On Aug 25, 2022, at 5:27 PM, Albert Dvornik via Boost wrote:

It looks like my previous message wasn't visible by non-HTML readers (including the list archive) because I didn't configure my so-called mailer correctly. Sorry for the duplication and the hassle.

bert

-------------------- Hi, all.

The definitions of boost::units::torque_dimension, boost::units::si::torque, boost::units::si::newton_meter and boost::units::si::newton_meters seem broken. The most obvious symptom of this is that boost::units::si::newton_meter isn't the same thing as boost::units::si::newton * boost::units::si::meter (i.e. an actual N m), but is instead defined to be equivalent to *N m / rad* instead.

I'm attaching a source file that shows the problem. I've compiled it with Boost 1.80, g++ 10.2.1.

Am I confused in some way? If not, then I believe that the fix would be to modify boost/units/physical_dimensions/torque.hpp and remove the ", plane_angle_base_dimension,-1" in the current definition of torque_dimension.

Regards, bert Dvornik

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost