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]

@kwikius 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.

Not all angles are measurable. Take theta in the above code. How are you to reach in to the mathemetical universe and measure it?

No; angles can also be calculated entirely in the mathematical universe . As I showed in the proof earlier, the output of an operation on dimensioned quantities can be a mathematical object.

mathematical objects with conversion_factors are very useful. In fact I used them in the implementation my own physical quantities libraries to do the heavy lifting of converting values without any of the dimensional analysis machinery:

https://github.com/kwikius/quan-trunk/blob/master/quan/detail/united_value/united_value.hpp https://github.com/kwikius/pqs/blob/master/src/include/pqs/bits/scaled_value.hpp

As shown in the constraint on the template argument in the ValueType template parameter in the second link, the base quantity there must be physically dimensionless ; a mathematical object.

Therefore : Just because an entity has a conversion factor doesn't mean it is physically present . So again the argument is a non sequitur ;

[mkrupcale]

@kwikius

Not all angles are measurable. Take theta in the above code. How are you to reach in to the mathemetical universe and measure it? ... No; angles can also be calculated entirely in the mathematical universe .

There are several problems with your argument here:

1. units is attempting to create the abstraction of physical quantities for dimensional analysis and scientific computing applications in the virtual domain of software (which I suppose one could argue is a high-level representation of a Boolean algebra). You are arguing here that the process is irreversible. If that is truly the case, then why are we even bothering with a physical units library? Only so we can have fun in the virtual software domain? No, there is a direct correspondence between angles in the physical and virtual domains, and the process is reversible, which is readily demonstrable: given an angle θ=90° in this virtual domain and a protractor, I can create an object in the physical domain of that angle measurement (or at least close enough for my needs). The reverse is obviously true as well: given a physical object which measures 90°, I can create a virtual representation.
2. This same logic can be applied to any other unit in units. If it were only possible to represent angles in the software domain, you can make the same argument for any other unit, in which case all units are "mathematical" in your terminology. Of course this is not the case, and all quantities and units (or at least the SI ones) have a physical correspondence.

So I ask you again: why do you insist on treating angles differently from other units when there is no logical difference?

As I showed in the proof earlier, the output of an operation on dimensioned quantities can be a mathematical object.

This is what you think you are doing in your alleged proof:

1. You start with the postulate that angles are a physical quantity.
2. From this, you make a claim that postulate 1 implies that "numbers" are also a physical quantity.
3. You prove that claim 2 is false.
4. You assert that if claim 2 is false, postulate 1 is also false.
5. Thus, angles are a "mathematical object",

where you define "mathematical object" in in axiom 3 as "numbers" without physical units. This use of "numbers" should actually be "quantities" so as to avoid confusion with pure (dimensionless) numbers. That is, your second and third axioms, respectively, should for clarity read:

A physical quantity is a number with a physical unit. A mathematical object is a number without a physical unit.

Under your terminology a "quantity" then is either a "physical quantity" or a "mathematical object", and a "mathematical object" is a dimensionless quantity.

Now, there are several problems with your alleged proof:

1. Your postulate "angle is a physical quantity since...", while making a true statement (that angles are physical quantities), does so on the basis of the ratio of physical quantities of the same dimension, which are obviously dimensionless. Thus, the only unit dimensions you can construct with this are powers of your physical length dimension, but angles are an entirely orthogonal dimension to length. So you are actually making a postulate on false grounds and ignoring the proper grounds for the postulate, i.e. that angles are physically measureable quantities of an independent, orthogonal dimension to lengths. You do this because you want to make the following point 2 in order to disprove this postulate.
2. You then claim (without proof) from your postulate that a "number is a physical quantity" on the grounds that it might be based on a ratio of physically measurable quantities. This is not proven, unless you consider this to be some sort of definition of a physical quantity, but this definition contradicts your previous one. To be clear, "number" here must actually be a "quantity" since you are not (yet) saying that a "number" here is a pure (dimensionless) number. Specifically, your claim then is actually that "a quantity involving the ratio of physically measurable quantities is a physical quantity".
3. You then use a specific example of a ratio of a quantity which is simply a ratio of quantities (physical or mathematical, i.e. with dimensions or dimensionless) of the same dimension. This is of course dimensionless, i.e. a "mathematical object". This does not disprove claim 2, however, since there could be more general quantities calculated based on such ratios. In particular, you have again neglected that angles might have an orthogonal dimension to lengths.
4. Even though you have not disproven claim 2, let's suppose that you did for the sake of argument. Putting aside that you do not prove that postulate 1 implies claim 2, except by some unspecified definition, in order for you to disprove postulate 1, you have to prove that claim 2 implies postulate 1. You have not done so again, unless you consider postulate 1 and claim 2 some sort of definition contrary to your original definitions.

You have made errors in nearly every step of your proof, and you have not proven anything about angles being (only) mathematical. This alleged proof was so full of errors that it was almost impossible to follow. The best I can surmise is that you conflated the concept of "number" (which is actually a "quantity") with dimensionless numbers, and this led you to (wrongly) conclude that angles are "mathematical objects", i.e. dimensionless quantities or pure numbers.

All you have actually shown is that numbers are dimensionless quantities, which is a direct result of dimensional analysis. Just because they can be calculated using physical quantity ratios does not change the rules of dimensional analysis. So all you are proving is that one cannot distinguish dimensionless quantities, whether they are calculated using physical quantity ratios or "mathematical object" (number or dimensionless quantity) ratios. This is of course obvious and a direct result of the rules of dimensional analysis, which leads to the incoherence of SI with dimensionless angles. For some reason you assert this as proof that angles are dimensionless and therefore "mathematical objects", but you are just outright assuming it despite the fact that there is no way to distinguish these dimensionless quantities. That is, you priviledge this "mathematical object" interpretation for angles without justification and use circular logic.

Again, we arrive at the question: why do you insist on treating angles differently from other units?

mathematical objects with conversion_factors are very useful. In fact I used them in the implementation my own physical quantities libraries to do the heavy lifting of converting values without any of the dimensional analysis machinery:

Again, conversion factors are simply a result of dimensional analysis. There is nothing surprising about this, and you are again making a distinction of "mathematically dimensionless" and "physically dimensionless" when there is none: there is only dimensionless.

As shown in the constraint on the template argument in the ValueType template parameter in the second link, the base quantity there must be physically dimensionless ; a mathematical object.

Great, you have chosen to treat angles as "mathematical objects" which are dimensionless in your own library. That is certainly your right, but it does not make it a correct reflection of the physical world.

Therefore : Just because an entity has a conversion factor doesn't mean it is physically present . So again the argument is a non sequitur ;

You have proven nothing about the physical or non-physical nature of angles. You only continue to assert without evidence and a faulty proof (again because the proof itself makes the same unsupported assertion) that angles are "mathematical objects".

I don't know how many times I have to go through this with you, but you think you are refuting the physical nature of angles, and you are not. I have provided actual physical support for my argument, and you simply make assertions without evidence. Not to mention you haven't refuted any of the many other points I made in [1].

I have already shown that there is a direct correspondence between angles in the physical world and the virtual domain, which is a reversible process. Now tell me: if I can measure an angle in the physical world with a physical tool such as a protractor, how is this any less physical than measuring a length in the physical world with a physical tool such as a ruler?

If you cannot refute this extremely simple argument without circular logic and esoteric, nonsensical definitions, there is no point in continuing the discussion.

[1] https://github.com/mpusz/units/issues/99#issuecomment-752974089

[JohelEGP]

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.

[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] https://github.com/mpusz/units/issues/99#issuecomment-751302060 [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 \ 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. https://github.com/mpusz/units/discussions/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 https://github.com/mpusz/units/issues/99#issuecomment-628654512.

[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] https://github.com/mpusz/units/discussions/195

[mpusz]

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

[mpusz]

Done in V2