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.

[doganulus]

@mkrupcale Thank you for your reply. I don't add anything further.

[mpusz]

@mkrupcale

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

Could you please provide more info on this? Also, do you have any alternative ideas on how to support degrees for an angular dimension with its conversion ratio based on pi?

[mkrupcale]

@mpusz

Could you please provide more info on this?

I'm not sure this is really related to the discussion, but there are different types of infinite sets: uncountable and countable.

Countable ones are the ones like the set of natural numbers ℕ = {0, 1, 2, ...} or integers ℤ = { ..., -2, -1, 0, 1, 2, ... }. They are infinite but countably so. The rational numbers ℚ = { p/q : p,q ∈ ℤ, q≠0 } are formed by the ratio of countable sets (i.e. the ratio of integers), and thus the rational numbers are countably infinite.

The reals ℝ, on the other hand, form an uncountable set, meaning there is no injective map from the reals to the (countable) set of natural numbers. Since the rational ℚ and irrational numbers ℝ\ℚ are by definition disjoint sets, this also means that "almost all" reals are irrational.

If you're interested in further information on this topic, I'd suggest looking into one of the many books on (real) analysis[1-5], but I'm not sure how this discussion helps resolve the issue of dealing with π in conversions. The point is that either you need to approximate π as a rational number (due to finite memory) or use a method which treats π as a convenient, rational constant or as a symbol.

Also, do you have any alternative ideas on how to support degrees for an angular dimension with its conversion ratio based on pi?

Did you see the end of this comment[6]? Unless I misunderstand, I'd say option 1 here is somewhat similar to the suggestion[7] of @i-ky except that the method of @i-ky uses π somewhat symbolically and explicitly carries it throughout the conversion, rather than internally and implicitly setting π=1 as I suggest.

[1] Pugh - Real Mathematical Analysis [2] Tao - Analysis I [3] Zorich - Mathematical Analysis I [4] Courant - Introduction to Calculus and Analysis I [5] Amann - Analysis I [6] https://github.com/mpusz/units/issues/99#issuecomment-752177728 [7] https://github.com/mpusz/units/issues/99#issuecomment-752223220

[kwikius]

Regarding use of pi:

I have found 2 separate concepts of angle useful.

One I called "mathematic_angle", useful for radian ,steradian and math trig operations .

The other I called "fraction of revolution", useful for counting integer (or rational) fractions of a revolution, e.g. degree, revolution, minute, second and degree*10^-7 ( used for example in ardupilot for transport of GPS lat and long as an integer, though they don't use UDT's: ) are examples.

Implicit conversion is provided between the 2 types and implicitly to from a real type for mathematic angles, since in the limit a mathematic angle is the same as a real: https://en.wikipedia.org/wiki/Small-angle_approximation. (Bear in mind that I have found both these angle concepts great for my own use, but I am not suggesting they are a way forward for standardization)

Both angle concepts can be used instead of a type representing real numbers for what mpunits calls "Rep type" for quantities in my personal quan library.

Conversion between the two angle concepts is the main place pi is required.

I have found for example 90_deg much more comprehensible for source code legibility than angle::rad::pi/4 ( representing pi/4 radians in my old c++98 work) and conversion to mathematic angle for trig pretty much perfectly optimised out and a good trade off where I have used them in embedded systems.

Here is an demo example using both types. https://github.com/kwikius/quan-trunk/blob/master/quan_matters/examples/angles2.cpp

and here is a more complex example of use in a small real world application https://github.com/kwikius/ArduIMU/blob/master/visualisation/complementary/complementary_algorithm.cpp#L31

So making what mpunits calls the Rep type an angle can also work, without requiring another dimension for angles.

[i-ky]

@mpusz, maybe we should move this issue into Discussions? There are several sub-topics being discussed:

1. angle as a new SI base dimension (and SI improvements in general)
2. fancy conversion factors like π, note that this goes beyond angles, e.g. parsec is 648000 / π astronomical units, i.e. current definition is an approximation https://github.com/mpusz/units/blob/112cce1c6521831ec0b0f996c4958432cf5cfb13/src/include/units/physical/si/iau/base/length.h#L34
3. abstract mathematics and whatnot

As far as I understand Issues have "linear" structure, whereas Discussions are "tree-like", which makes them more suitable for "parallel" topics.

[kwikius]

@i-ky, @doganulus , @mkrupcale

As I understood it mp-units had already incorporated angle as a dimension ( Not that I think that is a good idea!)?

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

[mpusz]

@kwikius, it was actually your work that made it happen ;-)

Even though we have radians we do not know what to do with degrees. Also, when we gain some experience, we have to decide how to progress with the standardization effort (with or without angles).

[kwikius]

As I keep saying and showing source for. You can have angles as its own library. angle as UDT can work very well as the Rep type. Just provide the Concept for RepType. Now you don't need to worry about degrees radians conversions factors etc. That is someeon elses problem. Maybe Rep type concept will need to be modified to allow angles as a model at a later date, but that is normal isnt it?

Beware trying to modify Dimension concept to make angle work as a dimension. As I keep saying Dimension needs to be entirely separate from unit/ numeric value, then conversion factors, constants etc are irrelevant in context of dimension, then life is simple.

[kwikius]

@kwikius, it was actually your work that made it happen ;-)

Even though we have radians we do not know what to do with degrees. Also, when we gain some experience, we have to decide how to progress with the standardization effort (with or without angles).

Re-read everything above and see how angles as dimension will cause more and more problems. This is for the SI to solve not a C++ library, which should concentrate on implementing what has already been solved.

Just leave angles out! This is implied in SI since torque is dimensionally equivalent to energy in SI. Also look at the other issues with angles which justify a separate library, how to treat multiple revolutions etc, etc.

The equivalence of torque and energy in SI is a good marker to show that the library should stick to the basics and not try to solve problems that the SI hasn't solved.

Again I have to point to my solutions where calculation on dimensionally equivalent quantities may resolve to an anonymous quantity, which the programmer explicitly makes a l-value torque or an energy if they wish ( so no downcasting). In fact I think you like angle as dimension since it is a partial solution to keep downcasting in? All these things are linked , which is why after many years I ended up with the solutions I did.

[kwikius]

We need to take care to avoid confusing the mathematical dimension with the physical dimension. Same word but entirely different concepts. The mathematical object e.g angle exists in multi-dimensional space (vector space ? ) but this refers to a mathematical dimension not a physical dimension. This brings us again to the issue of generalising a units library by moving away from the rule that a the base-quantity must be a physical quantity. I would suggest follow the SI and limit dimension to being comprised of physical quantities only. That is solid and well tested ground.

It is much easier to later relax a rule that is too strict than to try to tighten one that is too loose.

[JadeMatrix]

Just as a reminder, there aren't just two rotational systems (radians vs. degrees). There's also minutes-of-angle, seconds-of-angle, "rotations," and arbitrarily more depending on the application. Whatever route is taken should be generalizable to any rotational division.

@kwikius

angle as UDT can work very well as the Rep type. Just provide the Concept for RepType.

Could you explain this a little further? I'm not clear on the semantics this would imply — isn't the rep/storage type how the value is stored internally (e.g. double)? Wouldn't this mean you could have meters or amps stored as radians? Is this intended semantics and if so what would it mean? Would meters<Rep=numeric> be linear meters, and meters<Rep=angular> be arc length?

Beware trying to modify Dimension concept to make angle work as a dimension. As I keep saying Dimension needs to be entirely separate from unit/ numeric value, then conversion factors, constants etc are irrelevant in context of dimension, then life is simple.

Is this the real-world concept of a dimension or this library's concept of a dimension? I would like it to be kept as arbitrary as possible so users can introduce their own "dimensions" not recognized by SI. This may be what you're saying, sorry. My units library was purposely designed without dimensions codified for this reason. As I see it, the pros & cons from a code perspective:

• Without dimensions codified, you need a (fairly large and tedious to set up) database of conversions
• With dimensions codified, you can greatly reduce the scope of the database
• If you want to take advantage of the simpler database (with codified dimensions), you then need a base unit for each dimension to serve as lingua franca — which means all other units in that dimension are "second class citizens." I believe this is the current approach in mp-units (though thankfully 🙏 without the implicit intermediate conversions & loss of precision from some other libraries taking this approach).
• You can take both approaches: use codified dimensions for C++ Concepts (in hope of better performance & error messages), keep the tedious database so all units are "equal." Now you have about twice the code complexity to maintain.

[JadeMatrix]

Clarification on why I chose to not use codified dimensions: One of the two main driving factors for writing my library was representing pixels-vs-points for more correctly handling displays of arbitrary DPI. These both represent "length" but cannot have a fixed conversion factor as it relies on the display the current window is in (application may have multiple windows across multiple monitors of different DPIs). Mixing the two up causes rendering bugs; see Adobe Acrobat on Windows.

This may be what you're saying, sorry.

I would suggest follow the SI and limit dimension to being comprised of physical quantities only.

@kwikius Ah, thanks for the clarification. I guess we disagree then, like I said I'd like it as arbitrary as possible. As I see it SI is only concerned about scientific units standards, but dimensional analysis has a much broader range of applications.

[kwikius]

Just as a reminder, there aren't just two rotational systems (radians vs. degrees). There's also minutes-of-angle, seconds-of-angle, "rotations," and arbitrarily more depending on the application. Whatever route is taken should be generalizable to any rotational division.

As previously stated I have found 2 types of angle concept useful. The first considers angles as fractions of a revolution(You can make the actual fraction a template parameter, which gives you "minutes-of-angle, seconds-of-angle, "rotations," and arbitrarily more depending on the application")

The second is mathematic angles radians and steradians etc.

For example. supose you are storing angular position using output of a quadrature encoder

Clearly the choice of angle concept used to store position should be obvious there. Storing in radians would be unacceptable, but a fraction of revolution with an integer rep type works perfectly. the current shaft angle can of course be converted to radians as required.

[JadeMatrix]

@kwikius I think I see — is this mainly to avoid unnecessary lossy conversions using a π constant?

[mkrupcale]

@kwikius

As I understood it mp-units had already incorporated angle as a dimension ( Not that I think that is a good idea!)?

Yes, if you had completely read my first comment[1], you would have seen this. You continue to put forward arguments with several problems that you fail to address on the grounds that you have solved these problems in a different way in your own library.

Firstly, you continue to make this pseudo-philosophic argument that angles are somehow mathematical and not physical. I suggest you read the articles and books that @dwith-ts and I have presented on these topics[1,2]. If you do this, you will quickly see that angles are:

1. Both physical and mathematical
2. Not inherently dependent on length
3. Not inherently dimensionless

You can try to refute these facts, but these are supported by actual physics and metrology experts.

Secondly, you argue that treating planar angles as an independent dimension is inconsistent with the SI, which I and others have already acknowledged[1]. However, you do not acknowledge the advantages of doing so nor the fact that the SI is a living standard, like any standard including the C++ standard. As @mpusz hinted[3], the SI units once (before 1995) treated planar angles as a supplementary unit[4]. Furthermore, the articles cited in [1] are all within the past 6 years and are clearly referring to the current 9th Ed (2019) SI standard with the suggestion that it might be modified in the future to handle planar angles better than it currently does.

Thirdly, as @i-ky pointed out[5], apparently planar angles are not unique with respect to their use of π as a conversion factor. So regardless of how we handle planar angles, this issue of how to deal with irrational conversion factors has to be addressed.

Finally, as pointed out by @JadeMatrix and myself, it does not make sense for you to use (only) the Rep parameter for angles. These are orthogonal and independent concepts in the units library[6], and to do so only causes confusion and conflation of these concepts.

Final thoughts

To conclude, just because you have chosen to handle angles differently in your own library does not mean that this is the most suitable design of a units library for dimensional analysis and scientific computing applications. I agree with @JadeMatrix that the design should be general enough to allow the user to define their own unit systems. In order for this to work well, the design should be as clear and yet as general as necessary. The former requires us to not confuse and conflate orthogonal concepts, while the latter requires us to use (only) as many concepts as necessary.

Yes, there are issues associated with treating planar angles as a base dimension, but this appears to be the direction that the physics and metrology experts suggest taking the SI. They wouldn't be doing so if the current SI were already suitably handling units because of the work involved in doing so, but clearly there is confusion and ambiguity surrounding it that they feel should be addressed. This difficulty has been similarly addressed in other units software libraries[3] for a reason, and the metrology experts acknowledge that this is probably a good choice for software.

We already have what I think are viable solutions in the works for dealing with the remaining challenge of how to handle conversions with π, and this must be addressed regardless of how we address the planar angle situation.

[1] https://github.com/mpusz/units/issues/99#issuecomment-751302060 [2] https://github.com/mpusz/units/issues/99#issuecomment-752233950 [3] https://github.com/mpusz/units/issues/99#issuecomment-626341875 [4] https://www.bipm.org/en/CGPM/db/20/8/ [5] https://github.com/mpusz/units/issues/99#issuecomment-752737330 [6] https://github.com/mpusz/units/issues/99#issuecomment-752177728

[kwikius]

@kwikius

angle as UDT can work very well as the Rep type. Just provide the Concept for RepType.

Could you explain this a little further? I'm not clear on the semantics this would imply — isn't the rep/storage type how the value is stored internally (e.g. double)?

I hope the typedefs in the links clarify it. The typedefs should clarify how it is used, bearing in mind c++98 https://github.com/kwikius/quan-trunk/blob/master/quan_matters/examples/angles2.cpp#L32 https://github.com/kwikius/quan-trunk/blob/master/quan_matters/examples/angles2.cpp#L36 https://github.com/kwikius/quan-trunk/blob/master/quan_matters/examples/angles2.cpp

Wouldn't this mean you could have meters or amps stored as radians?

If you mean with a radians reptype then, yes this is acceptable. The exact semantics would depend on the Rep type. The most simple example is radians per sec equivalent to frequency but with a radian RepType. This is used in OpenGL App in following link ( app visualises the attitude of an IMU on a PC) to be absolutely clear about the units of the input from the gyro sensor and the typesafety continues throughout the code. https://github.com/kwikius/ArduIMU/blob/master/visualisation/complementary/complementary_algorithm.cpp#L126

This input has arrived from a real working sensor an ArduIMU, powered by an Arduino microcontroller. Units are also used on the application running on there https://github.com/kwikius/ArduIMU/blob/master/ArduIMU/sensors/gyr_sensor.h

The great strength of the units throughout these examples is as typed source documentation

Would meters<Rep=numeric> be linear meters, and meters<Rep=angular> be arc length?

Yes. What it actually means is up to the programmer ultimately, as long as it follows the rules for the Reptype and the physical quantity rules.

[kwikius]

@kwikius I think I see — is this mainly to avoid unnecessary lossy conversions using a π constant?

fraction of revolution ( where the fraction is simply the number of bits specifying one revolution) with an integer Rep type for quadrature decoder output gives exact shaft position. Using radians here would cause incremental errors. Integer rep type for radians is probably not much use!

[kwikius]

@kwikius ... Firstly, you continue to make this pseudo-philosophic argument that angles are somehow mathematical and not physical. I suggest you read the articles and books that @dwith-ts and I have presented on these topics[1,2]. If you do this, you will quickly see that angles are:

1. Both physical and mathematical

I refute this. In the link https://arxiv.org/pdf/1409.2794.pdf it states "One way to point out the odd status of angles within the SI is as follows: angle is measurable with a scale, on a protractor, in analogy to the way length is measureable with a ruler. It can therefore have units that are chosen by the user. This simple point is reinforced by the fact that multiple units for angle are used in practice. Angle measurements often use the degree, while the radian, which is used in mathematics and theoretical physics, is the SI unit. Other units, such as the grad, are used in specialised areas. And yet angle is treated as being dimensionless in the SI"

Like a physical quantity , a concrete angle (concrete implying it has a meaningful value) it must have units defined but that doesn't stop it being a mathematical object. ( physically dimensionless)

Rather than talking more in the abstract, let us do some C++ since that is the endgame. (If you wish to test this code, download my quan library (and point your compiler at the top-level directory)

The important thing to realise is that there are units here but no physical dimensions, hence the above quoted argument is a non sequitur

#include <quan/out/angle.hpp>
#include <quan/fixed_quantity/literal.hpp>
#include <quan/fixed_quantity/operations/atan2.hpp>
#include <quan/fixed_quantity/operations/abs.hpp>

QUAN_QUANTITY_LITERAL(angle, deg)
QUAN_QUANTITY_LITERAL(angle, rad)

void f()
{

   auto theta = 90.0_deg; // instantiate a type representing an angle

   std::cout << theta <<'\n';

   theta = quan::angle::pi / 2.0;  // an r-value angle in different units . Any concrete angle needs to have units of course

   auto y = sin(theta);  // n.b  x and y each have a geometric dimension
   auto x = cos(theta);

   // can we recover by synthesis the original angle?

   auto theta1 = quan::atan2(y,x); // do we wish to type enforce the different x y geometric dimension here now then?

   std::cout << theta <<'\n';

   if (theta1 == theta){
      std::cout << "perfect match\n";   // I get here on my pc. Your mileage may differ!
   }else{
      std::cout << "diff = " << abs(theta- theta1) << '\n';
   }

}

int main()
{
   f();
}

3. Not inherently dimensionless

Do you mean here geometrically dimensionless or physically dimensionless?

[kwikius]

Clarification on why I chose to not use codified dimensions: One of the two main driving factors for writing my library was representing pixels-vs-points for more correctly handling displays of arbitrary DPI. These both represent "length" but cannot have a fixed conversion factor as it relies on the display the current window is in (application may have multiple windows across multiple monitors of different DPIs). Mixing the two up causes rendering bugs; see Adobe Acrobat on Windows.

For display I usuallly found it best to find the physical display size https://github.com/kwikius/aerofoil/blob/master/aerofoilView.cpp#L54 and then draw in physical units (mm usually). https://github.com/kwikius/aerofoil/blob/master/aerofoilDoc.cpp#L61 That said I am usually doing things that need physical units! so if screen size changes you just present scroll bars if necessary and keep same physical image size

[mkrupcale]

@kwikius

I refute this. In the link https://arxiv.org/pdf/1409.2794.pdf it states...

Your citation here should refer to [1], not [2]. Nonetheless, the quotation you are citing supports my argument: it states clearly that angles are measurable (and therefore physical) and can have units specified by the user. Yet, the SI oddly chooses to "treat" them as dimensionless, which I and others have acknowledged as a source of confusion, ambiguity, and error. However, this does not refute the fact that angles are physical. Books on Lagrangian or Hamiltonian classical and quantum mechanics as well as the existence of protractors readily demonstrate this.

Like a physical quantity , a concrete angle (concrete implying it has a meaningful value) it must have units defined but that doesn't stop it being a mathematical object. ( physically dimensionless)

Again, here you are outright asserting through some pseudo-philosophic argument that despite angles having a physically measurable value (you use the word "concrete", which you define as "meaningful"?), you wish to claim it is dimensionless and only mathematical. You just state this as a fact despite physics and metrology experts suggesting otherwise.

Rather than talking more in the abstract

I'd like to point out that you are also making esoteric and abstract arguments by defining terms like "mathematical dimension" and "physical dimension" in nonsensical ways which are contrary to their ordinary meaning. Ordinarily, the concept of "mathematical dimension" refers to the number of degrees of freedom such as n-dimensional Euclidean space, while "physical dimension" might mean a mapping of those dimensions onto e.g. spacetime. However, you are somehow conflating both with a units dimension which is actually more akin to a mathematical dimension in the sense of their orthogonality, despite the fact that they measure physical quantities.

let us do some C++ since that is the endgame. (If you wish to test this code, download my quan library (and point your compiler at the top-level directory)

Something like this code example is of course achievable with an independent planar angle dimension. I fail to see why you think otherwise (I'm assuming your library does not treat planar angle as a dimension, otherwise, why are we even discussing this?) and insist on treating angles so much differently from other units.

The important thing to realise is that there are units here but no physical dimensions, hence the above quoted argument is a non sequitur

What does this even mean, "no physical dimensions"? Again, you are asserting without proof that angles are not physical, despite clear evidence to the contrary. It makes no sense to say simultaneously that angles have units and yet do not have dimension unless those units are one, i.e. dimensionless. If you choose to treat angles as a dimensionless quantity for some reason, you're inviting the issues of incoherence[2].

Do you mean here geometrically dimensionless or physically dimensionless?

Dimensionless quantities are a concept of dimensional analysis. Pure mathematicians have little care for dimensional analysis, and there is no "geometrically dimensionless" or "physically dimensionless"--only dimensionless. This is part of the problem with treating angles as dimensionless: incoherence[2].

If you read [1,2], you will see that angles are not dimensionless because while ratios of either lengths or areas (which are obviously dimensionless) can be used to calculate them, the angles themselves are independently, physically measurable and do indeed have units. This means that they have a dimension, i.e. are not dimensionless.

[1] Angles are inherently neither length ratios nor dimensionless [2] Dimensionless Units in the SI