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
#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 #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] #171 (comment)

[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

[kwikius]

My conjecture is that angle is a mathematical object, because it can be defined completely in a mathematical universe

I agree that my proof was not complete at all. Originally it was designed to disprove the conjecture that if the arguments to a function are physical quantities, then the output must also be a physical quantity. The conjecture was being used ( somewhere above, not by yourself as far as I remember) to claim that angle is a physical quantity, so a partial success.

I agree that the purpose of a units library is to try to define physical quantities as mathematical objects. The problem is that physical quantities can't be defined completely as mathematical objects since they need arbitrary measurements in the physical world to make sense, so in S.I. the so called base_units, which rely on external measurements from the physical universe. However angle can be defined completely in mathematical terms. It needs no physical stuff to be measured and tagged as its base_unit.

Informally an angle with a value of 1 or Pi has a mathematical meaning. A physical quantity with a value of 1 or Pi is mathematically meaningless.

[mkrupcale]

@kwikius

My conjecture is that angle is a mathematical object, because it can be defined completely in a mathematical universe

And again, you ignore what I am saying. You don't need to prove that the angle is mathematical. Obviously you can use angles in a virtual or mathematical "universe", as is true of any other SI unit. What you need to prove is that an angle is somehow sufficiently different from other quantities and that it is not physical.

I agree that my proof was not complete at all.

No, it is not incomplete--it is completely flawed and inconsistent.

Originally it was designed to disprove the conjecture that if the arguments to a function are physical quantities, then the output must also be a physical quantity.

I know what you were trying to do, and it does not work for the reasons stated in my previous post.

The conjecture was being used ( somewhere above, not by yourself as far as I remember) to claim that angle is a physical quantity, so a partial success.

Yes, which is contrary to your final conclusion. If you concluded that angles are physical quantities, then we would have no disagreement.

However angle can be defined completely in mathematical terms. It needs no physical stuff to be measured and tagged as its base_unit.

By that same logic, you do not need a physical measurement to define a length, and you can define them as purely mathematical objects. This is not proof that angles are not physical, only that they are also mathematical, like any other unit.

You continue to ignore the simplest argument for proof that angles are also physical: they can be measured and constructed in the physical world with a physical object called a protractor. Yet you insist they are different from lengths which are measured and constructed in the physical world with a physical object called a ruler.

Informally an angle with a value of 1 or Pi has a mathematical meaning. A physical quantity with a value of 1 or Pi is mathematically meaningless.

Indeed. This is the point clearly made by [2] and myself, which only supports my argument that an angle needs a dimension so as to avoid incoherence, confusion, and ambiguity.

[1] #99 (comment)
[2] Dimensionless Units in the SI

[kwikius]

My view on dimensional analysis in regards to software libraries is to enable stronger typing. If it can be counted, it can have its own dimension. If I can make an expression including SI units that makes sense, it can have its own dimension. I believe this is in line with the idea of having program-defined dimensions with mp::units. It even has an use case at https://mpusz.github.io/units/use_cases/extensions.html#custom-base-dimensions.

In this case, I can say that I walk x meters every y radians. So radian can have its own dimension. I have no doubt about it.

Now the question, for me, is how to apply stronger typing to it so that it can be useful like the other dimensions. That is, to enable crafting better software, moving accidents from Mars to compile-time.

A good baseline would be formulas involving dimensionless quantities. The idea is to have the code resemble the formulas as much as possible. In regards with the complexity and lack of safety of C++ implicit conversions, all other contexts should require, by default, being as explicit as possible.

Remember I did actually implement angle as dimension for you too experiment with

https://github.com/mpusz/units/blob/master/example/experimental_angle.cpp

All you now need to do is

1. implement the equivalent of <cmath> for it ;)
2. Convince the S.I. to change their definition of torque to match the mp units definition before units goes in the C++ standard !

[kwikius]

@mkrupcale

Remember I did actually implement angle as dimension for you too experiment with

https://github.com/mpusz/units/blob/master/example/experimental_angle.cpp

Good luck with the rest of the implementation !

[i-ky]

Dear @JohelEGP,

My view on dimensional analysis in regards to software libraries is to enable stronger typing.

Dimensional analysis will not provide 100% type safety on its own. It provides a good foundation with plenty of room for more layers (quantity kinds, etc.)

If I can make an expression including SI units that makes sense, it can have its own dimension.

Every quantity has a dimension. Even when we say "dimensionless quantity", we mean "a quantity of dimension one".

So radian can have its own dimension.

The big question causing heated debates here is whether angles should be a base dimension.

[JohelEGP]

Thank you.

The big question causing heated debates here is whether angles should be a base dimension.

I see. So the end result is whether its quantities are dimensionless or not. And all that entails. I think it (and any ratio of units that cancel out) can be made a base dimension until it's proven problematic. Making it otherwise would hinder the exploration mp::units set out to do to gather user feedback for standardization.

Thanks to @kwikius, angle is already a base dimension.

[kwikius]

Thank you.

The big question causing heated debates here is whether angles should be a base dimension.

I see. So the end result is whether its quantities are dimensionless or not. And all that entails. I think it (and any ratio of units that cancel out) can be made a base dimension until it's proven problematic. Making it otherwise would hinder the exploration mp::units set out to do to gather user feedback for standardization.

Thanks to @kwikius, angle is already a base dimension.

Not thanks to me Thanks to @mpusz. #105 I specifically made clear in the PR that it was not intended for inclusion in master. ;)

[kwikius]

Incidentally I am only concerned that angle should not be a base dimension in the S.I system mp-units implementation to conform to the S.I . If you wish to use it as such in your own system I have no objection.

Personally though I have found angles to be useful in their own right and have identified 2 separate concepts of angle. I believe that making angle part of a physical quantity type template will lose that flexibility. Overall I have argued for a more concepts base approach to units which would allow such flexibility since I can write my own conforming types
https://github.com/kwikius/pqs/blob/master/examples/chrono_duration_support.cpp

[mpusz]

Overall I have argued for a more concepts base approach to units which would allow such flexibility

Even though I liked the initial idea it does not work in practice. However, this is off-topic here and this tread is already long and hard to follow so if we want to start this discussion I recommend a separate thread in Discussions.

Coming back to angles. We had a really interesting discussion here. Thank you all for sharing your point of view. Unless there are new points of view or ideas we should probably start making some decisions on the future direction.

If I am not wrong here are all the possible solutions to address the subject (if some solution is missing, please let me know and I will update this table):

Solution	SI 2019 compliant	Pros	Cons
1. A base dimension	No	Makes angular calculations safer	We have to refactor SI definitions to make it work. Problems with rad <-> degree conversion factor
2. A dimensionless quantity unit	Yes	It works and is consistent with SI	Problems with rad <-> degree conversion factor
3. Dedicated representation types	Yes	Quite easy to implement	Dimensions and angles are orthogonal and additional effort is needed to ensure correctness
4. Just treat as numbers	Yes	The easiest solution 😉	Unsafe

The above does not mean we have to choose any of the solutions as of now. However, if we want to keep it as a viable solution for the future we have some work to do (unless we decide to follow with 4. 😉):
1, 2 - we need to figure out how to convert between radians and degrees.
1 - we need to provide alternative SI definitions for some dimensions. Probably should be done in a separate namespace.
3 - we need to implement such representation types.

If we fail to address any of the above issues we will have to drop a corresponding solution. If you favor any of the solutions please help in addressing its issues. Pull Requests are welcome 😃

[kwikius]

If I am not wrong here are all the possible solutions to address the subject (if some solution is missing, please let me know and I will update this table):

Simplest option is to ignore angles for now in SI system or provide options to select which flavour the user prefers; Vanilla SI angles which means following the book as currently writte,or some custom extension SI angles . If custom just remove any parts of Vanilla that might have angles in it and pull in relevant namespace for the custom angle library.

After all there are many other mathematical objects such as complex number and quaternion . It isnt necessary to provide all of them to make a useful library

[kwikius]

Problems with rad <-> degree conversion factor

Can you explain what is the problem with conversion factor between radians and degrees?
Anyway the solution is clearly to provide a separate dimension each for radians and degrees ;)

[JadeMatrix]

@mpusz I am not totally familiar with how your library is set up, but can't option 1 be used (base dimension) and simply leave out a unit definition for that dimension in the si:: namespace? (This is kind of besides the point, but I think the whole "systems of units" is an overcomplication from a code standpoint, anyways.)

[kwikius]

Overall I have argued for a more concepts base approach to units which would allow such flexibility

Even though I liked the initial idea it does not work in practice. However, this is off-topic here and this tread is already long and hard to follow so if we want to start this discussion I recommend a separate thread in Discussions.

I have done as requested. #194 I hope you will explain there why the generic programming approach to units "doesn't work in practise" I have provided links to the implementation which to my view seems to work very well in practise.

The concepts based approach could also be used to solve the radian degrees conversion issue, since it would allow various types representing angle in the library

[i-ky]

Dear @JadeMatrix,

can't option 1 be used (base dimension) and simply leave out a unit definition for that dimension in the si:: namespace?

Additional base dimension affects the whole dimensional analysis (in this case it is performed behind the scenes by the library). This means that equations from textbooks/papers will need some manual tuning. See #99 (comment).

[mpusz]

@kwikius

Can you explain what is the problem with conversion factor between radians and degrees?

If radian and degree are units (no matter if for an angle base dimension or for dim_one) we have to specify a compile-time conversion factor in units::ratio from radian to degree based on pi based on pi. It is not that easy at all.

[mpusz]

@JadeMatrix

I am not totally familiar with how your library is set up, but can't option 1 be used (base dimension) and simply leave out a unit definition for that dimension in the si:: namespace? (This is kind of besides the point, but I think the whole "systems of units" is an overcomplication from a code standpoint, anyways.)

I would like to keep si as "pure" as possible. This is why the angle base dimension is in the generic part right now rather than in si. Any non-si-standard extensions should be put in an external dedicated namespace/system (i.e. in si_angle_ext). Those should only redefine the derived dimensions that actually use this new angle base dimension while the rest will be taken directly from si namespace. This shouldn't be much work and we will have a clear "diff" on what changes are needed to update the si system definition with the angle extension for writing a potential dedicated ISO proposal.

[mkrupcale]

@mpusz

If radian and degree are units (no matter if for an angle base dimension or for dim_one) we have to specify a compile-time conversion factor in units::ratio from radian to degree based on pi based on pi. It is not that easy at all.

I've started a discussion on this particular topic if you have not already seen it[1].

[1] #195

[mpusz]

Thanks, I just got into it a few minutes ago...

[mpusz]

Done in V2