How to address radian and steradian?

[mpusz]

Those are officially dimensionless quantities. On the other hand, it is really handy to model them dimensions. Any opinions?

[kwikius]

FWIW I separated angles into two types which I called mathematic_angle and fraction of revolution.

The mathematic_angle basically consisted of radians to rational power N,D.

Fraction of revolution fits well exact rational fractions of revolution for degrees, gradian minute, revolution ( rpm) etc etc. Degrees are particularly useful for literals

I found it useful to have an implicit conversion from mathematic angle to/from its underlying floating point type( but not for fraction of revolution obviously!). Also implicit conversions between all the angle types. There is quite a lot of work to implement all trig functions etc, but strong angle types are nice to work with thus you can easily do double v = units::cos(45_deg); double v = units::cos(0.5_rad);

auto angle1 = units::atan2(dy,dx); angle1 is in radians

[i-ky]

Isn't this a duplicate of #27?

[mpusz]

@i-ky I do not believe so. Angular units are special. They were even considered for an official addition to extend SI base units. In fact some of the units libraries in the wild handle radian as a base unit: https://github.com/nholthaus/units/blob/master/include/units.h#L722.

[i-ky]

They were even considered for an official addition to extend SI base units.

That's news to me. Do you have any suggestions where I can read about that? I'm really curious how and why would someone introduce a dimensionless unit as a base unit. Let alone two of them...

I can't deny that they are special, but one can stretch "X is special" argument to infinity. For example, one might argue that % is a common (almost "standard") way of measuring discounts.

#27 has a real-life example of dimensionless units used in engineering which need to be distinguished from double.

[dwith-ts]

I would really love to see support for radian (i.e. radian being modeled as a real dimension) in this library!

Currenlty I am using a unit library which follows this approach and IMHO it is really nice to have a distinction between e.g. angular velocity [rad/s] and frequency [1/s] or between an angle in [rad] and all other dimensionless quantities.

@mpusz : we chatted very briefly after your talk at CppCon in case you remember...

Integrating angular units as proper units has some pitfalls that have to be considered, I don't think there is a solution which does not either surprise users that are used to "standard" physical equations or models just a small part of the problem.

There are the following options:

1. Model radian as a dimensionless quantity which is consistent but fails to prevent a whole class of errors / bugs by allowing to use any dimensionless quantity when actually angles are expected
2. Model radians as real angular units which means we need a solution to the now dimensionally incorrect equations which relate rotational to translational mechanics, e.g. for the arc-length s = r * theta where r is the radius of the circle and theta the plane angle. Without modifications, the arc-length would have unit [rad * m] if angle and lenght are measured in [m] and [rad] respectively. This can be solved by introducing an additional constant k (dimension angle^-1) which is integrated into this equation: s = k * r * theta

For details, see e.g. K.R. Brownstein: Angles—Let’s treat them squarely American Journal of Physics 65, 605 (1997) and also section "Opportunity 10" in https://iopscience.iop.org/article/10.1088/0026-1394/47/6/R01/pdf Unfortunately, both are behind a pay-wall unless your organisation has access.

A workaround which is similar to 2. (but does not cover all cases) would be to make [rad] disappear whenever it is multiplied with another unit in nominator / denominator, e.g. [rad/s] * [m] = [m/s]

Regarding the trigonometric functions, as these expect unit-less quantities they would also accept angular quantities but implicitly divide by the special constant k introduced earlier, i.e. something like sin(x) is defined as sin(k * x) if k == 1 [rad]^-1

[kwikius]

A problem with making an angle a base-unit of a quantity is that it merges angle into quantity and complicates the problem of providing angle specific operations, specifically trigonometry functions, so my guess is that it would end up being a limited partial solution, which will need to be redone at a later date with now extra backward compatibility issues.

One important difference that crops up a lot between angles and other numeric types ( on the "number line") is that angles are limited to a range of one revolution, so addition of 2 degrees to 359 degrees, should maybe wrap around automatically e.g to 1 degree. Also there is a choice of representation between angles that are always positive or that have a sign, so the issue of how to handle comparison of these numerically different but equivalent angles also arises.

As @mpusz says the complicating part of treating angle like numeric is that for example radian * radian --> steradian, so they show that characteristic with quantities, but are still said to be dimensionless quantities by S.I. but it should be possible to re-use much of the quantity dimension framework with angles, while making them a distinct concept.

Because of the unique nature of angles, I decided to make angle types that can stand on their, and don't depend on physical quantity at all, because they don't really fit as quantities or as numeric types, but are useful as the "Rep" type of a quantity without a doubt.

[kwikius]

The relationship between radians and numeric is seen where in the limit as the angle goes to 0 the circular arc length -> a straight line. I made radians and steradaians( but not other angle types) implicitly convertible to/from float for this reason. I found the most important place to differentiate radians from float is for output

[dwith-ts]

@kwikius : I made an edit to the last paragraph regarding the trigonometric functions, you are right that these would also need to be changed. Not sure if you read the edit when you commented.

[dwith-ts]

The relationship between radians and numeric is seen where in the limit as the angle goes to 0 the circular arc length -> a straight line. I made radians and steradaians( but not other angle types) implicitly convertible to/from float for this reason. I found the most important place to differentiate radians from float is for output

I would claim quite the contrary, the most important place to differentiate radians from float is in all calculations, i.e. more on the input side :-)

[i-ky]

Making radian a "dimension" will require a dimensional π, e.g. to make a relation between angular and ordinary frequency work (ω [rad/s] = 2π [rad?] × f [1/s]).

[i-ky]

Model radian as a dimensionless quantity which is consistent but fails to prevent a whole class of errors / bugs by allowing to use any dimensionless quantity when actually angles are expected

There are many quantities with length dimension, failing to distinguish them may also lead to errors / bugs. For example, you can mix up wavelength and diameter when estimating resolution of a lens. That's not the reason to introduce additional "dimensions".

Let's not forget, that quantity consists of dimension/unit and representation type. I agree with @kwikius that Rep should be used to distinguish angles from other dimensionless quantities.

[dwith-ts]

There are many quantities with length dimension, failing to distinguish them may also lead to errors / bugs. For example, you can mix up wavelength and diameter when estimating resolution of a lens. That's not the reason to introduce additional "dimensions".

Wavelength and diameter measure the same physical "thing", a length. An angle is not identical to a ratio of lengths, it is merely proportional to the quotient of arclength and radius.

Here is a nice paper explaining that in detail: https://arxiv.org/pdf/1909.08389.pdf (Angles are inherently neither length ratios nor dimensionless)

[dwith-ts]

But @i-ky 's comment is correct, that some parts of the usual physical equations would need to be changed if angles are no longer considered dimensionless, see Implications of adopting plane angle as a base quantity in the SI https://arxiv.org/pdf/1604.02373.pdf

The last sentence is interesting for us: "These underlying equations could have specialised uses, for example within quantity-calculating software, where they would ensure that the software correctly handles units involving angle and frequency."

[kwikius]

Here is a pull request so you can play with angles. I only implemented the "as a dimension" option though https://github.com/mpusz/units/pull/105

[i-ky]

Thank you for these links, @dwith-ts! It started to make a bit more sense after analogy with electric charge. But I'm afraid that without wide adoption of the new system, users of units library will struggle to find equations featuring η in books/papers. They will have to adopt equations on their own to implement them in code. This may lead to confusion and, consequently, bugs. Not everyone of us is a metrology expert.

[kwikius]

Though I did angle as dimension pull request https://github.com/mpusz/units/pull/105, I dont think that angle should be a dimension in si namespace, since in SI namespace Torque and Energy should be dimensionally equivalent, but with status quo that is not the case. Angle as dimension should be in a custom/ experimental namespace to retain compatibility with SI

[mpusz]

Looking at it from the other side, the fact that with angle as a dimension Torque and Energy are dimensionally different makes them nicely work with a downcasting facility 😉

[kwikius]

But

Looking at it from the other side, the fact that with angle as a dimension Torque and Energy are dimensionally different makes them nicely work with a downcasting facility wink

Unfortunately that that is not the way it is defined in the SI, so it really is interesting now to try to understand if the previous policy of mpusz/units to rigidly follow the SI has changed?

[kwikius]

Here is my latest thought on this subject :

Conjecture : angle is a mathematical object rather than a physical quantity

Proof:

axiom : A physical unit has its basis in measurement of a physical phenomena axiom : A physical quantity has a physical unit axiom : The set of mathematical object does not include numbers with physical units

Postulate : angle is a physical quantity since function f resulting in angle (codomain of f) may involve measuring the ratio between 2 physical lengths (domain of f). therefore : number is a physical quantity since function resulting in number may involve measuring the ratio between 2 physical lengths.

but if a and b are of same scalar physical quantity type or mathematical type

m = a / b

m (codomain) is in the set of mathematical objects whether or not the arguments of the function involved in its construction (domain) a and b are physical quantities

The same reasoning applied to number can be applied to angle ( including solid angle and plane angle)

QED : angle is a mathematical object rather than a physical quantity

[doganulus]

This is an interesting topic as being left underspecified in SI. I do not hold the view strongly but I would love to see "angular length" as a separate base dimension. This is of course equivalent to selecting "angle" or "the number PI" as base dimension but I enjoy the fact that the base dimension still has a physical meaning, where I would select the base unit to be the circumference of a circle with radius of 1m (that is, 2 PI meters).

Then the angle dimension would be derived as "angular length" over (linear) "length". Hence the SI unit m/m is clearly visible.

[mpusz]

@doganulus, this a really interesting approach. I am not a physics expert though. It would be great to get feedback from other experts on this too.

[mkrupcale]

@kwikius

QED : angle is a mathematical object rather than a physical quantity

Planar angles are mathematical only in the sense that historically they are defined using primitive geometry and trigonometry without regard to units. That is, trigonometric functions implicitly assume the use of radians because mathematicians are not usually concerned with the concept of physical units and dimensional analysis. See e.g. sections II and III of [1] for discussion. Thus, just because planar angles are defined based on a mathematical constant (i.e. π) rather than a physical constant of nature (e.g. Planck's constant h, Boltzmann constant k, speed of light c, etc.) does not mean that angles should not have a base unit.

@doganulus

Then the angle dimension would be derived as "angular length" over (linear) "length". Hence the SI unit m/m is clearly visible.

I don't think this is a good idea. While this would be consistent with the current SI definition[2] and allow for deriving an angular unit from the "angular length" or "arc length" base unit, there is nothing physically different about a curved length and a "straight" length: the former is simply a generalization of the latter. The articles[3,4] posted by @dwith-ts on this matter were informative and insightful and also support this argument that arc lengths are not special with regards to planar angles. In particular, the sections "Misconception: an angle is defined as the ratio of an arc length to a radius" and "Misconception: angle measurement requires length measurement" from [3] soundly refute the idea that lengths are required for defining planar angles at all. And "The case for making angle a base quantity" from [4] makes the point that radians are directly measurable on their own and not counted.

Combining these results leads one to conclude that planar angles are[1,3,4]:

1. Not inherently dependent on length
2. Not inherently dimensionless

A corallary then is that planar angles can be an independent base dimension A with base unit rad. The solid angle is of course then of dimension A^2 and derived unit sr=rad^2.

@i-ky

But I'm afraid that without wide adoption of the new system, users of units library will struggle to find equations featuring η in books/papers. They will have to adopt equations on their own to implement them in code. This may lead to confusion and, consequently, bugs. Not everyone of us is a metrology expert.

There will be a risk of confusion and misuse surrounding planar angles in scientific codes with our without a planar angle base unit. Defining the planar angle base unit requires one to modify some physical constants and equations as per [1,4]. Not defining the planar angle base unit requires one to be very careful around the use of dimensionless quantities so as to avoid conflating incoherent dimensionless quantities. Furthermore, the required explicit conversion of non-radian angle units to radians is equivalent to modifying the physical constants and equations as per [1,4], but this explicit dimensionless conversion loses the type-safety and coherence guarantees. With the angle base unit, you can do this same explicit conversion without modifying the equations and still get the type-safety and coherence guarantee.

Thus, I think it is best to define planar angle radians as a base unit, as is currently done by units[5]. This does have implications for the definitions of physical constants and physical equations[1,4], and it is inconsistent with the current SI unit system[2]. However, I think this will ultimately lead to a more robust, consistent, and coherent unit system for dimensional analysis and scientific computing applications[1,4].

[1] Dimensionless Units in the SI [2] SI, 9th Ed - Table 4 [3] Angles are inherently neither length ratios nor dimensionless [4] Implications of adopting plane angle as a base quantity in the SI [5] https://github.com/mpusz/units/issues/171#issuecomment-702172680

[kwikius]

As has been demonstrated angle is not a physical quantity, but if you wish to make it such, you should be allowed to do so. The quantity framework should allow the user to define their own systems. This is the approach I have taken in my own library. I have implemented 2 example systems, but there is no constraint that says you cannot design others with their own semantics and dimensions

Best of luck!

regards Andy Little

[JadeMatrix]

@kwikius

One important difference that crops up a lot between angles and other numeric types ( on the "number line") is that angles are limited to a range of one revolution, so addition of 2 degrees to 359 degrees, should maybe wrap around automatically e.g to 1 degree.

This may have more to do with the problem of affine types as mentioned here, I believe. There are situations where you want an angular value that "overlaps" with itself — rotation counts, for example.

[mpusz]

@mkrupcale, thanks for sharing your point of view in such detail with references to external docs. This is not an easy subject and controversies and inconsistencies in different unit libraries around with us for many years now. I must admit I share your point of view but I am not a maths or physics expert here, I just know Modern C++ 😉

but if you wish to make it such, you should be allowed to do so

This is what we decided to do in this library. We provide the tools and examples for others to define their systems. However, if we are about to standardize such an SI-like system as a part of the C++ Standard Library we have to decide how it should look like.

One important difference that crops up a lot between angles and other numeric types ( on the "number line") is that angles are limited to a range of one revolution, so addition of 2 degrees to 359 degrees, should maybe wrap around automatically e.g to 1 degree.

I think such wrapping can be easily provided with a custom representation type? However, in order to start talking about degrees, we have to find out a way to convert between radians and degrees. In other words, how to wrap pi into units::ratio and not overflow its value on at least simple calculations (i.e. creating quantities of solid angles).

[mkrupcale]

I must admit I share your point of view but I am not a maths or physics expert here, I just know Modern C++ wink

I'm not sure I can claim to be a physics expert, although I do have a physics degree. More importantly, though, I think this point of view is supported by [1,3,4] of my previous post, and these authors are actual physics and metrology experts. More specifically, [4] concludes that even though they do not consider the benefits of a planar angle base unit to justify the upheaval caused by redefining physical constants and equations--at least not without further consultation with the affected communities--these changes are probably appropriate in software where correctness is essential.

I think such wrapping can be easily provided with a custom representation type?

Yeah, this is what I thought as well. It seems like this is orthogonal to the unit or dimension, and the representation concept should be able to encapsulate this periodic numerical representation.

However, in order to start talking about degrees, we have to find out a way to convert between radians and degrees. In other words, how to wrap pi into units::ratio and not overflow its value on at least simple calculations (i.e. creating quantities of solid angles).

That is a challenge indeed. π is obviously irrational and therefore cannot be represented as a units::ratio without loss of precision. Two ideas immediately come to mind:

1. The user must input radians as a multiplier of π: i.e. Q = {Q} [Q], where {Q} = x*π, [Q]=rad, and units internally stores x. This is equivalent to internally defining π=1, and any conversions between radians and non-radians should result in π cancelling. It of course forces the user to determine x based on either a limited or arbitrary precision value of π and {Q} via the quotient x={Q}/π, though.
2. Generalize units::ratio to permit either fixed precision floating point or arbitrary precision representations. The former obviously causes problems with loss of precision possibly not acceptable under most circumstances (perhaps this is acceptable in the case of angles?), while the latter might complicate things significantly.

[doganulus]

Then the angle dimension would be derived as "angular length" over (linear) "length". Hence the SI unit m/m is clearly visible.

I don't think this is a good idea. While this would be consistent with the current SI definition[2] and allow for deriving an angular unit from the "angular length" or "arc length" base unit, there is nothing physically different about a curved length and a "straight" length: the former is simply a generalization of the latter.

@mkrupcale this cannot be an argument in favor of choosing radians as the base dimension instead. Both are functionally equivalent as one can say there is no difference between the number PI and a rational. The former (real numbers) is simply a generalization of the latter. But of course we know there is a difference**. All the literature of physics differentiates angular quantities from linear quantities so why the case of length would differ? That being said, the choice of the base dimension is purely a matter of convention as both choices are functionally equivalent for a software library. My suggestion is to select more-physical looking one.

Nonetheless this is good discussion though not much related to the library.

** Btw the difference is related to the infinite precision required to represent real numbers as implied above. Yes, we are not able to finitely represent them as rationals them but we can make their own seperate dimensions as long as the number of such real numbers is finite.

[i-ky]

how to wrap pi into units::ratio

I was thinking about it some time ago and the best approach I could come up with was quite "direct" — to store a rational exponent of π in units::ratio. Since π is transcendental, all operations on the rational part of units::ratio and the power of π can be performed independently and will never "leak" into one another, so it is relatively easy to implement. And unless different powers of π need to be added/subtracted this solution provides absolute precision. When printing, user may choose to keep π as is or to convert to a decimal. The biggest drawback is that this approach is π-centric, but I don't know any units that are based on irrational factors other than multiples π.

UPD: Well, there is 1 B = ln(10)/2 Np, but there is a separate issue to discuss logarithmic units. They are very special.

UPD2: Old (pre-2015) definition of parsec used tan(1").

[mkrupcale]

@doganulus

this cannot be an argument in favor of choosing radians as the base dimension instead.

Certainly it is. The point is that lengths are lengths whether or not they are curved. That is, curved lengths are an extension of straight lengths and are not independent properties, whereas angles and lengths are. You can see this because lengths require rulers whereas angles require protractors to measure, which of course are completely different and independent tools.

Both are functionally equivalent...

Can you calculate an angle using a ruler to measure curved lengths? Sure, but this is an indirect--not to mention tedious and error-prone pragmatically speaking--way of doing so when one has a protractor. Thus, the fundamental, orthogonal properties here are lengths and angles, not "curved lengths" and "straight lengths".

All the literature of physics differentiates angular quantities from linear quantities so why the case of length would differ?

This actually supports my argument. The equations of motion typically use angle and position to describe the dynamics, not curved position and position. That is, the equations of (Lagrangian) mechanics typically use a rotational coordinate like angle--not the position along the curve--as the (generalized) coordinate. This is convenient because rotational invariance implies conservation of angular momentum. See e.g. Goldstein Classical Mechanics section 2.6. This means that the angle is a more fundamental quantity than the curve position/length.

My suggestion is to select more-physical looking one.

And I am saying that angles are more physical than "curved lengths".

we can make their own seperate dimensions as long as the number of such real numbers is finite.

This is completely unrelated but nonetheless false. The real numbers are uncountably infinite, whereas rationals are countably infinite.

[JadeMatrix]

@mkrupcale

It seems like this is orthogonal to the unit or dimension, and the representation concept should be able to encapsulate this periodic numerical representation.

This brings up a good point, and a possible answer to #35 (tagging @i-ky since you also brought it up). Putting the burden on the storage type for non-linear / periodic / etc. representations reduces the scope of this library (in a good way) and possibly allows more flexibility.