Irrational conversion factors: planar angle and π

[mkrupcale]

Introduction

Currently, units handles[1] conversion between quantities using a conversion[2] units::ratio[3] which is a rational number with some exponent. This works for numerators and denominators of which fit into an std::intmax_t, but irrational constants such as π would have to be truncated, resulting in a loss of precision during conversion.

Proposed solutions

During the discussion of how to handle planar angle units[4], several solutions were proposed for how to deal with the issue of conversion[5,6]. These are summarized as follows:

1. Approximate π as a rational number[7-9]
2. Treat π internally as a convenient rational constant π=1 or purely symbolically with algebraic operations carried out symbolically
3. Permit either fixed precision floating point or arbitrary precision conversion factor representations
4. Create conversion abstraction/concept and punt to the user

In option 2, treating π=1 or π symbolically are somewhat similar, although I think the former is simpler to use and implement, and there is no real advantage of carrying π symbolically through the calculation since any exponents will already be carried through via the angle base dimension. Thus, we will consider only the former option π=1 here. Option 3 will be split into fixed and arbitrary precision options for discussion. Option 4, like option 3, requires coming up with an abstraction/concept for the unit conversion which generalizes units::ratio and allows the user to specify how the conversion should be done. Then the advantages and disadvantages of each option are as follows:

1. Approximate π as a rational number
   • Pro:
     1. Simple to implement: can use existing units::ratio conversion infrastructure
   • Con:
     1. Loss of precision
     2. Possibly prone to integer overflow during conversions
2. Treat π internally as a convenient rational constant π=1
   • Pro:
     1. Simple to implement: can use existing units::ratio conversion infrastructure
     2. No internal precision loss: internal conversions between radians and non-radians cancel π, so one can exactly represent non-radian units (e.g. degrees, grads, rotations, or any other angle unit without an irrational conversion factor besides π)
   • Con:
     1. Depending on Rep, there will be external precision loss during conversion to/from the units quantity. This will be controlled by the user, though.
     2. Requires user to convert to/from internal representation by dividing/multiplying by π when dealing with radians. This would include construction of angle quantities in radian units as well as most trigonometric operations on angle quantities. This is problematic because radians are probably the most important angle unit, but this internal representation essentially requires the user to externally keep a copy of the quantity x*π rad, where x is the internally stored angle value, in order to avoid extra div/mul operations. Maybe one could store internally both x*π and x to do the book-keeping for the user, but this doubles angle storage requirements, requires operating on both values, and makes a cumbersome API. This will likely lead to errors or just avoiding the use of units for angles altogether.
     3. Requires handling other irrational conversion factors besides π in a similar fashion, so additional irrational constants add additional mental burden and implementation complexity.
3. Permit either fixed precision floating point or arbitrary precision conversion factor representations
   1. Fixed precision floating point
      • Pro:
        1. Simple to implement: allow units::ratio conversion factor to be a float, double, or long double
      • Con:
        1. Internal precision loss
        2. Internal floating point operations (e.g. even with integral quantity representations)
        3. May make freestanding implementations difficult[10]
   2. Arbitrary precision
      • Pro:
        1. No more loss of precision than is necessary for conversion (limited only by memory or maximum precision allowed)
      • Con:
        1. Significantly more complicated to implement and standardize
4. Create conversion abstraction/concept and punt to the user
   • Pro:
     1. No more loss of precision than is necessary for user
   • Con:
     1. Requires new conversion abstraction/concept, complicating units design

I've probably missed some things here, but this can serve as a starting point for the discussion. For what it's worth, it looks like Boost.Units uses option 3.i with double precision[11].

Currently, I'm kind of inclined to say that option 4 (creation of a conversion abstraction/concept) might be the best option since we essentially allow the users to decide what their precision needs are when dealing with irrational conversion factors. This is kind of like the Rep concept which is general enough to allow e.g. integer, floating point, arbitrary precision, or periodic numerical representations, depending on what the user requires. The conversion however is not entirely independent from the Rep concept, so I'm not entirely sure what this conversion abstraction would look like and how it might depend on Rep.

References

[1] https://github.com/mpusz/units/blob/6d7cda949eee5c8d0428cbc16b685c497d92534f/src/include/units/quantity_cast.h#L107
[2] https://github.com/mpusz/units/blob/6d7cda949eee5c8d0428cbc16b685c497d92534f/src/include/units/quantity_cast.h#L59
[3] https://github.com/mpusz/units/blob/1ef2bf9f28020f29cb86a46548f4f41daf7518a6/src/include/units/ratio.h#L49
[4] #99
[5] #99 (comment)
[6] #99 (comment)
[7] https://oeis.org/A002485
[8] https://oeis.org/A002486
[9] http://qin.laya.com/tech_projects_approxpi.html
[10] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2268r0.html#floating_point
[11] https://github.com/boostorg/units/blob/21c9dcaf3a334692cf043ac70f86857a96431d4b/include/boost/units/base_units/angle/degree.hpp#L17

[kwikius]

specify angles in terms of a concept, and then you can write different angle types for the different purposes.
#194
#99 (comment)

[mkrupcale]

I reread your posts multiple times before I responded to make sure I wasn't missing something. I say again: making a quantity concept or an angle concept and having multiple angle types does not address the question of how to convert between the types with irrational conversion factors.

[kwikius]

The compile time rational conversion factor was only ever designed to represent conversion factors from incoherent quantities to coherent quantities in the S.I. system. That only needed 6 decimal places of precision when it was written in 2003. Maybe that changed to 7 decimal places by now.

To convert from radians to degrees and vice versa you need floating point math.

[mkrupcale]

The compile time rational conversion factor was only ever designed to represent conversion factors from incoherent quantities to coherent quantities in the S.I. system. That only needed 6 decimal places of precision when it was written in 2003. Maybe that changed to 7 decimal places by now.

This may be acceptable for your library, but a generic units library should not lose precision where possible. This becomes more complicated when dealing with irrational conversion factors, which is of course the purpose of this particular discussion.

To convert from radians to degrees and vice versa you need floating point math.

No, as my original post indicated, there are alternatives to the use of floating point math.

[JohelEGP]

This may be acceptable for your library, but a generic units library should not lose precision where possible. This becomes more complicated when dealing with irrational conversion factors, which is of course the purpose of this particular discussion.

I actually think we should give users a choice. Going for the a solution without precision loss could be prohibitively costly to some (in performance or otherwise). That's the whole point of floating-point types, its trade offs.

[mkrupcale]

I actually think we should give users a choice.

Yes, I agree. This is why I think we should pursue option 4 of my proposed solutions.

[kwikius]

What I mean is give up on the idea of making angle a quantity in mpunits type, using the compile time conversion factor. It really doesnt work vry well.

[mkrupcale]

Which part? Using a runtime conversion factor? I can see that argument, but we still are talking about a constant conversion factor. It's just that it's impossible to numerically represent in finite memory. In any case, I'm not sure why it shouldn't be possible to allow users to create currency units even if it is not standardized in units.

[kwikius]

money as a dimension is the slippery slope once you allow anything to be a base-unit.
It worked in Boost.Units apparently though...

[mkrupcale]

As I said, perhaps units need not standardize money units, but I see no reason that if users want to create such units they cannot. This is already possible with units, but the conversion ratios are compile-time constants.

[kwikius]

the conversion ratios are compile-time constants.

Yes, you can blame me for that!, as explained here The compile time units constants was my own original work in 2003-4. See here for an early version. https://github.com/kwikius/pqs/blob/master/doc/archive/pqs-2-00-02.zip ( see the ct_quantity/quantity_unit.hpp header there) Well it was Brandon Forehand that pointed out that my numbers were in fact compile time rational numbers. Thanks Brandon! (Prior libraries just provided base units. Everything was calculated in base units. See https://github.com/mpusz/units/blob/master/example/clcpp_response.cpp
and follow the link. http://compgroups.net/comp.lang.c++.moderated/dimensional-analysis-units/51712

As you can see even in 2006 the "experts" completely ignored the compile time units. ;)

Subsequently the compile time constant units idea has been subsequently misunderstood and abused in many units libraries and even in the C++ standard. Even std::chrono::duration got it wrong so duration can only express a very limited range of units.

[mkrupcale]

I have no problem with compile-time constants in general. In fact it is a very useful capability. However, this does not address the issue of how to handle irrational conversion factors.

[kwikius]

Here are 3 problem to solve.

1. write a C++ angle type capable of expressing angles in radians
2. write a C++ angle type capable of accurately holding the current position of a quadrature encoder.
3. For extra points solve both problem with one type

The 2 types don't have to be the same type and they dont need to have anything to do with mp_units types, nor to have any other functionality so should be quite quick to write

I have solved part2 with my venerable quan library using both types of angle, thus also showing a solution to part1. I didnt attempt part 3

int main()
{
   // number of encoder bits representing one revolution
   constexpr int encoder_bits_per_rev = 2100;

  // create a fraction of revolution angle type for incrementing by exactly one bit at a time
   using  encoder_angle_type = quan::fraction_of_revolution<
         quan::meta::rational<1>,
         quan::meta::rational<encoder_bits_per_rev,1>,
         int
   > ;

  // encoder angle representing one bit change
   constexpr encoder_angle_type encoder_incr{1};

  // current_angle_rad attempts to hold the current position using the standard angle unit , the radian
   quan::angle::rad current_angle_rad;  // so called mathematic angle
  // current_angle_fract attempts to hold the current position using the bespoke angle unit , encoder_angle_type
   encoder_angle_type current_angle_fract; // so called fraction of revolution
   
   for ( int i = 0; i < encoder_bits_per_rev; ++i){
      current_angle_rad += encoder_incr;
      current_angle_fract += encoder_incr;
   }

   std::cout.precision(20);
   std::cout << "current pos in rad = " << current_angle_rad / (2* quan::angle::pi) <<'\n';
   std::cout << "current pos in rev = " << current_angle_fract.numeric_value()/ encoder_bits_per_rev  <<'\n';
}

The output on my pc is

current pos in rad = 0.99999999999998467892
current pos in rev = 1

Clearly the best choice for this particular task is the custom fraction of revolution type.

So now to solve the problem using your angle type(s).

[mkrupcale]

Huh? conversion is provided by the library between the types, as demonstrated in the example!

I was referring to this line in your example:

   std::cout << "current pos in rad = " << current_angle_rad / (2* quan::angle::pi) <<'\n';

Here you require the user to manually convert from the angle in radians to the angle in revolutions with the use of the 2π conversion factor, which you define internally using a compile-time double constant[1,2].

In this line,

      current_angle_rad += encoder_incr;

you have an internal conversion from the encoder_angle_type to a quan::angle::rad again using a compile-time double constant[3,4]. This corresponds to option 3.i in my first post, similar to Boost.Units.

If problem 2 has been solved, it should be no more than a few minutes work to solve the challenge. I look forward to seeing the source shortly;)

Creating an angle type for degrees can be done in much the same way as the current angle type for radians is done[5,6]:

#include <units/generic/angle.h>

namespace units {

struct degree : units::named_unit<degree, "deg", physical::si::prefix> {};

template<UnitOf<dim_angle<degree>> U, QuantityValue Rep = double>
using angle_degree = quantity<dim_angle<degree>, U, Rep>;

inline namespace literals {

// deg
constexpr auto operator"" _q_deg(unsigned long long l) { return angle_degree<degree, std::int64_t>(l); }
constexpr auto operator"" _q_deg(long double l) { return angle_degree<degree, long double>(l); }

}  // namespace literals

}  // namespace units

using units::literals::operator"" _q_deg;

static_assert(180_q_deg * 2 == 360_q_deg);

This however does not address the problem of converting between the two units. For that, we would like to e.g. use a named_scaled_unit, but the units::ratio it requires will not handle an irrational conversion factor.

[1] https://github.com/kwikius/quan-trunk/blob/47b471c0237c6586a0a668aa946e6c9fa603eaf2/quan/angle.hpp#L1215
[2] https://github.com/kwikius/quan-trunk/blob/47b471c0237c6586a0a668aa946e6c9fa603eaf2/quan_matters/src/angle.cpp#L46
[3] https://github.com/kwikius/quan-trunk/blob/47b471c0237c6586a0a668aa946e6c9fa603eaf2/quan/angle.hpp#L53
[4] https://github.com/kwikius/quan-trunk/blob/47b471c0237c6586a0a668aa946e6c9fa603eaf2/quan_matters/src/constant.cpp#L36
[5] https://github.com/mpusz/units/blob/6d7cda949eee5c8d0428cbc16b685c497d92534f/src/include/units/generic/angle.h#L30
[6] https://godbolt.org/z/ErqYe8

[kwikius]

Huh? conversion is provided by the library between the types, as demonstrated in the example!

I was referring to this line in your example:

   std::cout << "current pos in rad = " << current_angle_rad / (2* quan::angle::pi) <<'\n';

Here you require the user to manually convert from the angle in radians to the angle in revolutions with the use of the 2π conversion factor, which you define internally using a compile-time double constant[1,2].

In this line,

      current_angle_rad += encoder_incr;

you have an internal conversion from the encoder_angle_type to a quan::angle::rad again using a compile-time double constant[3,4]. This corresponds to option 3.i in my first post, similar to Boost.Units.

You originally asserted the following ( which you have omitted in your reply)

"Your solution to the angle conversion problem is to leave that to the user."

Now you acknowledge that "you have an internal conversion from the encoder_angle_type to a quan::angle::rad"

So the original statement. "Your solution to the angle conversion problem is to leave that to the user."

is false.

---

The angle in degrees code is a good start ( there is nothing about an encoder, but it could be extrapolated from that), but ...

you are now happy confirming that there are 2 types of angle ( whereas there is only one type of length for example where the base unit measurement is an imprecise arbitrary constant anyway) . Ideally radian would be a base unit, but as you discover that doesn't really work to convert to the other angle type, due to the compile time rationals, because the conversion factor between the two types involves a precise but irrational mathematical constant rather than an arbitrary physical measurement. IOW they are different types in the same way reals and integers are different

QED. The compile time rationals work fine for converting from incoherent units to base_units in the SI system, but extrapolating that to arbitrary "systems of units" is problematic in many ways. That was never the original intent as i have discussed previously and I spend time when possible recommending just sticking to the original useage, but without much success unfortunately.

[mkrupcale]

You originally asserted the following ( which you have omitted in your reply)

"Your solution to the angle conversion problem is to leave that to the user."

This is what you do in the final piece of code, the first one I cited where you directly compare the two angle unit outputs in revolutions.

Now you acknowledge that "you have an internal conversion from the encoder_angle_type to a quan::angle::rad"

Yes, for construction of a quan::angle::rad.

So the original statement. "Your solution to the angle conversion problem is to leave that to the user."

is false.

No, you have both an internal conversion for construction and an external conversion for output in revolutions. This latter conversion is the one to which I was referring.

you are now happy confirming that there are 2 types of angle ( whereas there is only one type of length for example where the base unit measurement is an imprecise arbitrary constant anyway) .

No, you are misunderstanding my use of the word "type". I am using "type" here to refer to a C++ type. I am not using "type" in some abstract sense to indicate that they are somehow so incompatible with one another that they must be of independent dimensions. Angles--whether in radian, degree, or revolution units--are all of the same dimension (i.e., the planar angle dimension A), and they are convertible albiet with potentially irrational conversion factors.

Ideally radian would be a base unit, but as you discover that doesn't really work to convert to the other angle type, due to the compile time rationals, because the conversion factor between the two types involves a precise but irrational mathematical constant rather than an arbitrary physical measurement.

Yes, I know. That is the entire point of this discussion: how to solve this issue of irrational conversion factors.

QED. The compile time rationals work fine for converting from incoherent units to base_units in the SI system, but extrapolating that to arbitrary "systems of units" is problematic in many ways. That was never the original intent as i have discussed previously and I spend time when possible recommending just sticking to the original useage, but without much success unfortunately.

"Original intent"? "Original usage"? Again, you are free to make your own choices for your own library. That does not mean that your intentions and uses are the optimal choice for units or for standardization.

[kwikius]

QED. The compile time rationals work fine for converting from incoherent units to base_units in the SI system, but extrapolating that to arbitrary "systems of units" is problematic in many ways. That was never the original intent as i have discussed previously and I spend time when possible recommending just sticking to the original useage, but without much success unfortunately.

"Original intent"? "Original usage"? Again, you are free to make your own choices for your own library. That does not mean that your intentions and uses are the optimal choice for units or for standardization.

My prior original intent and useage already later did get standardised in std::chrono::duration.

Have a Nice Day ;)

[mkrupcale]

My prior original intent and useage already later did get standardised in std::chrono::duration.

std::chrono::duration has none of the complexities associated with a generic units library like units. Namely, it is one-dimensional and does not have to worry about irrational conversion factors. Obviously a library with such simple design intentions and uses does not need to deal with the complexities of general unit systems, so I don't know what your point is.

[mpusz]

And what if we redefine units::ratio to:

struct ratio {
  std::intmax_t num;
  std::intmax_t den;
  std::intmax_t exp;
  std::intmax_t pi_exp = 0;  // <-----
  // ...
};

It addresses only pi factors and not answer a generic conversion factor question but maybe it is good enough?

Alternatively, we could make ratio a concept, and more than one type could be provided there so user could provide their own. I am afraid that in such a case we would have many problems with the explosion of operators for different ratio types and lack of interoperability between different libraries introducing their own ratio types...

[mpusz]

@mkrupcale

I think it would at least make sense to additionally support option 3.i (float, double, long double conversion factors), since that appears to be a popular compromise choice.

I am pretty sure it will not work correctly. For example, an international mile has a specific conversion factor. If during floating-point calculations you will end up with a ratio different by 1 ULP you will end up with a unit of a different type (not an international mile anymore).

[mpusz]

@mkrupcale

Do you have an idea what a Ratio concept might look like? Does it need only support multiplication and division?

Sure, take a look here: #194 (comment).

[mpusz]

Option 3.ii might make sense in more mathematical contexts

It might be useful as an alternative but not as the primary solution. I am afraid that it will impact the performance of runtime conversions too much.

[mkrupcale]

I am pretty sure it will not work correctly. For example, an international mile has a specific conversion factor. If during floating-point calculations you will end up with a ratio different by 1 ULP you will end up with a unit of a different type (not an international mile anymore).

Yes, that's why it is a compromise choice: the user may be willing to sacrifice precision for simplicity of floating point conversions where required (e.g. irrational conversion factors). This is not much different than the conversion between radian and radian_pi using std::numbers::pi_v you suggested[1].

Sure, take a look here: #194 (comment).

Thanks, I hadn't seen that until you posted. This does indeed look like a more complete Ratio concept. I'm not sure common_ratio should be required, though. I don't know if floating points would be able to support this function.

It might be useful as an alternative but not as the primary solution. I am afraid that it will impact the performance of runtime conversions too much.

Indeed, I was not suggesting this as the primary solution. I was suggesting that the Ratio concept should support this use case. With the exception of compile-time multiplication and the common_ratio function, I think this is possible.

[1] #195 (reply in thread)

[mpusz]

I'm not sure common_ratio should be required, though. I don't know if floating points would be able to support this function.

Well, we always have to be able to provide a common ratio for all the different ratio types used in a calculation. The more the merrier 😉 This is why I am really careful with introducing more than one ratio type.

[mpusz]

2. ... Requires user to convert to/from internal representation by dividing/multiplying by π when dealing with radians

It can be enforced with dedicated Rep types for degrees and radians but is orthogonal to a unit provided in a quantity type and may be hard to keep consistent by the user.

[i-ky]

struct radian : named_unit<radian, "rad", physical::si::prefix> {};
struct radian_pi : named_scaled_unit<radian_pi, "rad_pi", physical::si::prefix, ratio(1,1,0,1), radian> {};
struct rotation : named_scaled_unit<rotation, "rot", physical::si::prefix, ratio(2), radian_pi> {};
struct degree : named_scaled_unit<degree, "deg", physical::si::prefix, ratio(1,360), rotation> {};

I have no objections other than:

1. "rotation" is a process, unit seems to be called a "turn";
2. some would call radian_pi a "multiples of π".

But that's 100% bikeshedding. :)

[mpusz]

I am not sure if we even need a rotation/turn unit. It was just a showcase of possible solutions here. Please let me also know if radian_pi is needed at all. I provided it only because you were discussing such a use case above.

And we need good names for those if we decide to keep them.

[i-ky]

I am not sure if we even need a rotation/turn unit. It was just a showcase of possible solutions here.

I suppose it would be nice to have revolutions per minute as a unit of angular velocity, rotation/revolution/turn would be a nice complement.

Please let me also know if radian_pi is needed at all.

Short answer: yes. From my point of view it is more important than radian. I do believe it is more important to represent "important" angles (aka "fractions of revolution" as @kwikius calls them) like 30°, 45°, 60°, 90°, etc. because of symmetry groups and human psychology. I'm OK to waste a few CPU cycles.

I'm also afraid that mp-units will be judged by how well it can handle these special cases in small code snippets that may have little relation to real-life scenarios. radian will inevitably accumulate some round-off error after a number of turns and will require additional epsilon-style manipulations to "round" to a nearest full rotation. This is a perfect ground for nitpicking.

However, my humble experience with angle measuring devices tells me that even in real-life scenarios angle values will "revolve" around rational fractions of a turn. It is just too difficult to produce instruments for measuring angles in radians.

[mkrupcale]

The purpose of radian_pi here really is only to allow exact conversions between radian_pi, rotation, degree, and any other rational angle units. The conversion between radian and radian_pi necessarily is going to involve precision loss (due to finite memory). How much precision loss will depend on ratio and the convert function. radian_pi basically is only acting as an intermediary between the other non-radian units and thus I don't think it's really necessary: you could instead just directly convert radian to degrees. You will still have the loss of precision, but it's one less step. I really don't expect many people to directly use radian_pi. I suspect they'd be more likely to use degree, turns, or any other non-radian units if they need exact (i.e. integral) angle representations.

Also, providing units::ratio with pi_exp does increase the structure size for a very special application, and this does not account for any other irrational conversion factors such as e or φ. I'm not sure any other units have such irrational conversion factors, but this solution does not really generalize well.

[mpusz]

How much precision loss will depend on ratio and the convert function.

Actually the most important here will be the representation type provided by the user.

but it's one less step

The library is implemented in a way that all the conversions are immediate (not performed in steps). Steps are only used and useful for units definitions. Actual conversions convert right away based on a compile-time precalculated factor.

providing units::ratio with pi_exp does increase the structure size for a very special application,

Ratio never uses runtime memory. It is a pure compile-time data structure. So we should not be concerned with its size too much.

does not account for any other irrational conversion factors such as e or φ

I do not think it is easier to have a regular_ratio, ratio_for_pi, and ratio_for_e and then write op* and op/ for all the combinations of those. In which type you will store a ratio being a result of ratio_for_pi * ratio_for_e and how would you calculate the factor? This is my biggest concern with providing a Ratio concept.

[i-ky]

2. ... Requires user to convert to/from internal representation by dividing/multiplying by π when dealing with radians. This would include ... most trigonometric operations on angle quantities.

Overloads of trigonometric functions taking angle (or dimensionless) as an argument should be provided as it is done for exp():
https://github.com/mpusz/units/blob/5c6cd1b26b1ce0cebda2512dd2f9c44ab8022d0c/src/include/units/math.h#L102
Multiplication by π will happen automatically and user will not have to worry about it.

However, when using .count(), user will have to multiply by π "manually", but this is no different to e.g. multiplying by 1000 when dealing with kilo.

essentially requires the user to externally keep a copy of the quantity x*π rad, where x is the internally stored angle value, in order to avoid extra div/mul operations.

I wonder if one extra multiplication/division operation will make any difference when trigonometric functions are involved.

[mkrupcale]

It's not just the book-keeping issue, though (i.e. manually vs. automatically multiplying/dividing by π). There should ideally be no overhead involved in simply using units, and floating point mul/div ops are relatively expensive. Sure, 2 ops might be small when compared to a trig function (depending on the path taken according to the angle value), but it would be best to avoid if possible, and this overhead adds up over many conversions.

[mpusz]

floating point mul/div ops are relatively expensive

Well actually I was surprised too but this is not the issue anymore. See #174 (comment)

[mkrupcale]

Well it depends on what you mean by "relatively expensive" of course. I wasn't necessarily comparing to integer mul/div, but rather I was comparing to just loading the value from the quantity, which is what one would do if no conversion were necessary for usage. For example, for Skylake/Zen1/Zen2, we have[1-3]

instruction	latency	reciprocal throughput (CPI)
movss/movsd	1 <= T <= 4	0.25 <= CPI <= 0.5
mulss/mulsd	3 <= T <= 4	0.5
divss/divsd	8 <= T <= 14	3 <= CPI <= 5

So the floating point divisions are still relatively expensive compared to loading. The multiplications are also more expensive but perhaps not significantly so.

[1] https://www.agner.org/optimize/instruction_tables.pdf
[2] https://software.intel.com/sites/landingpage/IntrinsicsGuide
[3] https://uops.info/table.html

[mpusz]

I still think that we might leave the choice to the user with a proper set of units (#195 (reply in thread)).

[JadeMatrix]

Just a few ideas I've been kicking around:

Using a concept

Regarding a concept solution, such a concept could be one of two types: units::ratio or a new units::irratio. The latter would be the counterpart to ratio but for irrational constants such as π. In its simplest form, irratio could be defined something like:

struct irratio
{
    long double val;
};

irratio is infectuous: multiplying or dividing:

• a ratio with a ratio returns a ratio (as it does now)
• a ratio with an irratio returns an irratio
• a irratio with an irratio returns an irratio

When toying with an implementation for irratio, I found it would be nice to preserve ratio::exp in operations, meaning irratio becomes:

struct irratio
{
    long double   val;
    std::intmax_t exp;
};

So now you've got two very similar types with special operator logic, wrapped up in a concept. Though better than allowing any number of ratio-like types, that sounds very annoying to implement and work with.

Instead, maybe combine the two — which bears some resemblance to the idea for dedicated factor members:

struct ratio
{
    std::intmax_t num;
    std::intmax_t den;
    long double   irr; // Irrational part
    std::intmax_t exp;

    // Naively modified mult operator
    [[nodiscard]] friend constexpr ratio operator*(
        const ratio& lhs,
        const ratio& rhs
    )
    {
        const std::intmax_t gcd1 = std::gcd(lhs.num, rhs.den);
        const std::intmax_t gcd2 = std::gcd(rhs.num, lhs.den);
        return ratio(
            detail::safe_multiply(lhs.num / gcd1, rhs.num / gcd2),
            detail::safe_multiply(lhs.den / gcd2, rhs.den / gcd1),
            lhs.irr * rhs.irr,
            lhs.exp + rhs.exp
        );
    }
};

This isn't an ideal solution either, as the original irrational part constants are "lost" through floating-point multiplication. A separate exponent for the irrational part could be used:

[[nodiscard]] constexpr auto pow(long double v, std::intmax_t exp)
{
    // Implementation conveniently left as an exercise to the reader
}

struct ratio
{
    std::intmax_t num;
    std::intmax_t den;
    std::intmax_t exp;
    long double   irr; // Irrational part
    std::intmax_t ire; // Irrational part exponent

    [[nodiscard]] friend constexpr ratio operator*(
        const ratio& lhs,
        const ratio& rhs
    )
    {
        const std::intmax_t gcd1 = std::gcd(lhs.num, rhs.den);
        const std::intmax_t gcd2 = std::gcd(rhs.num, lhs.den);
        return ratio(
            detail::safe_multiply(lhs.num / gcd1, rhs.num / gcd2),
            detail::safe_multiply(lhs.den / gcd2, rhs.den / gcd1),
            (
                lhs.irr == rhs.irr
                ? lhs.irr
                : pow(lhs.irr, lhs.ire) * pow(rhs.irr, rhs.ire)
            ),
            (lhs.irr == rhs.irr ? lhs.ire + rhs.ire : 1.0),
            lhs.exp + rhs.exp
        );
    }
};

This preserves the irr value when multiplying two units with the same irrational part; it's still "lost" when different irrational parts are combined. The assumption here is that:

• users will care more about preserving it when multiplying like units (power operations)
• users will care less about preserving it when multiplying disparate units
  Ideally it would always be preserved, but perhaps this covers the "99%" cases? I don't know.

Notably this also requires a constexpr pow() that works on the type of ratio::irr (long double for example), unlike units::modpow().

Leveraging <numbers> compatibility

Switching gears entirely now — this isn't really a solution, but possibly the seed of one. An irrational part could be added as a template template, either to quantity or ratio.

• Downside: this adds as much or more complexity compared to the above "irrational part" idea
• Upside is it puts the onus of preserving the desired level of precision on the Rep type chosen by the user

I'm going to call this thing for now since it could be added in a number of places:

template<template<typename> class IrrationalFactor> struct thing
{
    template<typename Rep>
    static constexpr auto value = IrrationalFactor<Rep>::value;
};

template<typename Thing1, typename Thing2> struct thing_mult
{
    struct type
    {
        template<typename Rep> static constexpr auto value = (
              Thing1::template value<Rep>
            * Thing2::template value<Rep>
        );
    };
};

template<
    Thing ThingL,
    Thing ThingR
> [[nodiscard]] constexpr auto operator*(
    const quantity< /*...*/ ThingL /*...*/ >& lhs,
    const quantity< /*...*/ ThingR /*...*/ >& rhs
)
{
    using new_thing = typename thing_mult<ThingL, ThingR>::type;
    return quantity< /*...*/ new_thing /*...*/ >( /*...*/ );
}

Ideally, π as a factor in units would then be represented by thing<std::numbers::pi_v>. However I'm not aware of a way to pass a template variable as a template parameter, so some additional boilerplate is required:

template<typename T> struct factor_pi
{
    static constexpr auto value = std::numbers::pi_v<T>;
};
template<typename T> struct factor_one
{
    static constexpr auto value = static_cast<T>(1);
};

thing<factor_pi> then resulting in its value member being std::numbers::pi_v<Rep>. Multiplying two units with π factors would result in value being std::numbers::pi_v<Rep> * std::numbers::pi_v<Rep>. (Quick & dirty compiling example)

If Rep is double, then it was if std::numbers::pi was used all along. If in an imaginary case where the user supplied a Rep that tracked powers of π (and also specialized std::numbers::pi_v appropriately), that would be preserved.

With the rough implementation above, there is no way to cancel out irrational factors. It could probably be achieved through partial specializations of thing_mult/thing_div, and probably much simpler than my method of units reduction[1] as it would be limited to a binary-tree-like of operations.

[1] Main "algorithm" here, meat of it here — warning, this originally targeted C++11

[chiphogg]

Thanks---I had forgotten about the other proposals in your original post in this thread. Lots of creative ideas! Which one was your second proposal? It wasn't clear to me how you were numbering them.

Also, did any of them have a path to exact symbolic computation (i.e., perfect "cancellation" for arbitrary rational powers of arbitrarily many irrational constants)? I consider this a hard requirement (and, relatedly, keeping floating point math from leaking into the types). I tried figuring out a way to get there, but I wasn't able to see it for any of these options. (Granted, I had less motivation because we already have a working solution... but when it comes to the future C++ standard, the more options we can have at our disposal, the better!)

[JadeMatrix]

Which one was your second proposal? It wasn't clear to me how you were numbering them.

Using the template constants defined in the std::numbers namespace as the symbols for π etc.

Also, did any of them have a path to exact symbolic computation (i.e., perfect "cancellation" for arbitrary rational powers of arbitrarily many irrational constants)?

Yes, it's supposed to. I didn't implement it in this example because it's tedious, but I did link to some of my code that does basically the same thing, so I know it's possible. My older code uses void specializations to simplify the code, since that was possible due to the templates all being library-defined. This might not be practical with template variable symbols, as they ideally would follow the std::numbers conventions exactly — you'd probably have to forward the Rep types around everywhere. On the other hand, the code for reducing them would also be simpler, so it may come out the same complexity-wise.

I consider this a hard requirement

Given that this library is unlikely to change its entire design approach, yes. There's two distinct concepts here: 1) wrapping numbers in type information conveying the units and 2) symbolic math for minimizing loss of precision. As we're seeing here, handling all units in the same dimension as multiples of a "blessed" unit forces you to integrate symbolic math into the unit type logic, rather than something that's only used when converting between units. Using a relationship system with no "blessed" units, maintaining symbolic representations could be left to a more generic Rep type (I think this has been brought up before), possibly supplied by a third-party library. Take converting radians to degrees as an example:

• Using a Rep of double, this would result in a division of a double value by std::numbers::pi_v<double> — a loss of precision, but possibly completely acceptable for a large number of use cases
• Using a hypothetical arithmetic type (or template) symbolic_t, this would result in a division of a symbolic_t by std::numbers::pi_v<symbolic_t>. This would be a specialization that points to the "π symbol" recognized by the symbolic_t operators, allowing it to be carried along with no loss of precision.

I'm not saying mp-units should be completely redesigned — this is just an observation. In my experience, the number one most common units-related error in programming that a units library would help fix is mixing up degrees & radians, and I'm just a little (personally) disappointed that angular support was not a higher-priority design factor.

(and, relatedly, keeping floating point math from leaking into the types).

Not sure what you mean. The variable templates (not specializations of them) are being used directly as symbols there.

[chiphogg]

I'm not saying mp-units should be completely redesigned — this is just an observation. In my experience, the number one most common units-related error in programming that a units library would help fix is mixing up degrees & radians, and I'm just a little (personally) disappointed that angular support was not a higher-priority design factor.

I agree: angular support is critical for a units library. A lot of people get beguiled by the misguided view that angles are somehow "intrinsically" dimensionless, and thus shouldn't be part of a units library. I've made that mistake in the past, too. @mkrupcale's clear posts on the matter, in other issues in this repo, were very influential in my thinking, especially in leading me towards persuasive and easily shared arguments such as this one. Once we started using angles as first-class citizens in our units library, there were a few edge cases here and there that were slightly tricky, but the benefits were overwhelming---it was almost pure win.

(and, relatedly, keeping floating point math from leaking into the types).

Not sure what you mean. The variable templates (not specializations of them) are being used directly as symbols there.

Yeah, I think I might have gotten myself confused here. I was thinking that the type of q1 * q2 * q1 * q2 should have been equivalent to quantity<double, thing<factor_121>> (assuming factor_121 were defined in the obvious way). My goal was to show that, since the value was not equal to 121, then floating point math had corrupted the types.

But thinking more about it, it seems like even if the value was the same, the types wouldn't be. So maybe the problem would be even simpler to demonstrate: namely, that if you had factor_11, then a product of types with factor_11_pi and factor_pi_inv wouldn't give that type, just some other type with that same value.

That said---you've linked to a solution from your own units library, so it sounds like you've figured out a way past this... awesome. 😎

[JadeMatrix]

Yeah, I think I might have gotten myself confused here. I was thinking that the type of q1 * q2 * q1 * q2 should have been equivalent to quantity<double, thing<factor_121>> (assuming factor_121 were defined in the obvious way). My goal was to show that, since the value was not equal to 121, then floating point math had corrupted the types.

But thinking more about it, it seems like even if the value was the same, the types wouldn't be. So maybe the problem would be even simpler to demonstrate: namely, that if you had factor_11, then a product of types with factor_11_pi and factor_pi_inv wouldn't give that type, just some other type with that same value.

Wow, looking back I guess I didn't make that part clear at all. Key to the entire thing is in the actual version, you'd replace the basic thing_OP<...>::type structs with the appropriate reduction metaprogramming. That's the tricky part I hand-waved and pointed to my implementation.

So this:

thing_div<
    thing_mult<
        thing<factor_pi>,
        thing<factor_pi>
    >,
    thing_mult<
        thing<factor_pi>,
        thing<factor_pi>
    >
>::type

would be an alias for:

thing<ratio_factor_factory<1,1>::template factor>

... or something along those lines. Cancelling explicit inverted factors like your factor_inv_pi might not be possible, you'd probably want to build them up using thing_div.

The basic principle for mine was first reduce the combined set of types (degenerate void unit specializations) to a single numer/denom parameter pack pair, then scan through one, dropping an instance of a type from both if it appeared in both. I make no claims this had its origin in the mind of greatness, just a week of vacation time devoted entirely to it. It takes advantage of the fact I was already storing the tags in parameter packs, and that I could use the void specializations to slightly reduce the complexity. So I only linked it to show it is theoretically possible, not that I think I know the best way to implement it.

[chiphogg]

Ah---this makes much more sense. Thanks for fleshing out the missing piece of the puzzle! Reduction metaprogramming makes much more sense. And yes, I would prefer to define factor_inv_pi using thing_div; cancellation is easy with this approach and hopeless without it.

[mpusz]

irratio is infectuous: multiplying or dividing:
a ratio with a ratio returns a ratio (as it does now)
a ratio with an irratio returns an irratio
a irratio with an irratio returns an irratio

So if I take i.e. si::kilometre_per_hour defined in terms of ration and multiply it and then divide by irratio I will not get back si::kilometre_per_hour as a unit 😢
It is one of the reasons I believe a concept approach for Ratio will not work, but you are welcomed to prove me wrong 😉

[JadeMatrix]

Yeah, which is why I introduced the ire member to mitigate it. The template template approach (with cancellation added) would not have this issue.

[burnpanck]

If I read the comment by @mpusz above correctly, a design goal is to provide "exact" units computation, so that we can retain human-readable units through computations. Here, with "exact unit computation" I mean that no approximations shall enter the units represented by the type-system, not necessarily the runtime values. I find that a reasonable goal.
However, if we now also want to enable "exact" value computations with those units, we cannot approximate irrational prefactors found in units into the runtime value either. To me, that is an equally valid design goal.

Therefore, I believe the only solution is to treat those irrational factors symbolically. The simplest one is definitely a std::intmax_t pi_exp, or potentially a units::ratio pi_exp to include square root computations. That is the solution taken by the nholthaus::units library. I find that inelegant, because it singles out pi as the "blessed" one irrational constant to support.

I would favour a system that allows products of rational exponents of arbitrary symbolic constants to be retained. This would enable exact and free computation with frequent constants in domain-specific cases, such as the speed of light or other physical constants when working in natural units.

Technically, that will require a system quite similar to the current unit system, which also enables products of exponents of arbitrary symbolic base units. This is why a separate dimension for angles appears like a solution. However, I think that is misleading. Separating dimensions (or equivalently base units) is something we do because it helps avoiding wrong computations by making it less likely that accidentally two "incompatible" quantities happen to have the same unit. Separating symbolic constants however we do to prevent numerical representation issues. That is, the rules when and how conversions that apply pre-factors should be done (both automatic/implicit and explicit) are significantly different between those two cases.

In fact a separate dimension/base-units for angles does not solve the pi issue on it's own, unless there are two separate base units, one including the pi constant, the other not. Instead, the separation of angles into its own base dimension tries to solve a different goal: To prevent accidental mixing of dimensionless quantities of the "angle" kind with dimensionless quantities of other kinds (such as "ratio"). However, in some cases, those distinction becomes blurry and makes computation awkward, e.g. when working with trigonometric functions decomposed into exponential functions. Therefore, I believe where to put that distinction is an application specific compromise in the same way that certain domains prefer to work with natural units, where essentially all dimensions are equivalent (less protection, more convenience), while others prefer to work in SI units (more protection, less convenience).

[JadeMatrix]

@burnpanck @mpusz this sounds similar to what I was proposing in the second half of my comment here: #195 (comment)

I think it's better to utilize the numeric constant template variables already defined by the C++20 standard library, rather than introducing new ones specific to this library. Any novel irrational constants required by users would be usable as long as they follow these established conventions of the standard library.

What should be the results of ratio<pi> * ratio<e>? Should it be allowed?

It is possible to maintain "symbolic ratios" (as I also mentioned in my comment above), the only cost being compile-time complexity.

[burnpanck]

@JadeMatrix I agree, what I propose is not fundamentally different. I didn't want to focus on the technical detail, but on the larger concept: We want a generalised compile-time "constant factor" type, which is able to represent products and powers (with rational exponent) of at least the constant "pi" but preferentially any symbolic constant without precision loss. This can only be achieved with symbolic calculation, for which you presented a form of.

The names in your proposal are focused on ratios and irrational numbers. The same concept would more generally apply to symbolic constants of any type, e.g. physical constants which are only approximately known (therefore rational / irrational doesn't apply at all), but still can be managed symbolically. Furthermore, your proposal doesn't show explicitly how the identity of the "symbolic <thing>" is being kept track of, which is important to be able to cancel ratios like pi/pi as they arise in computations. It could definitely be implemented, though I would design that constant factor data structure with that requirement in mind from the beginning.

Because of the symbolic simplification/cancellation that we need, the numeric constant templates of the C++20 standard library will not work. They are variable templates not class templates, therefore they do not have a compile-time type identity that could be used. Of course the approximations we associate with those symbols should be provided by the standard library, if it happens to have that value.

I want to stress again that such a symbolic product of rational powers of abstract symbolic "factors/constants" has almost exactly the same technical requirement as a physical derived dimension in this library, which is a symbolic product of rational powers of abstract symbolic "base units". The only difference is that those "factor symbols" are not associated with a dimension, and therefore do not impact unit compatibility. The template argument list of the derived dimension contains <Exponent ...Es>, where each of those Exponent is in fact a factor of a symbolic base dimension to a rational power: Mathematically Es::dimension ^ (Es::num / Es::denom), where Es::dimension is considered an abstract mathematical symbol. That exact same role has the the <SymbolicPower ...Sp> factors in my exhibition only illustration of the concept I describe. The derived dimension implementation already implements symbolic cancellation and canonical ordering, so with a bit of refactoring that same implementation could be used to support both functions. We'd create a basic symbolic Factor concept that doesn't constrain the nature of the "base symbol", and refine it to two concepts where one constraints the base to a "base dimension" and the other to a "symbolic constant".

[mpusz]

I am happy to see this chapter evolve as it seems to direct towards one more interesting use case for my ISO C++ proposal for C++23: http://wg21.link/p2008. With such a feature we would need to introduce an additional type (pi_symbol) to wrap a variable template but just use the variable template directly as a variable template template parameter.

The feature was welcomed by EWGI and was passed to EWG after the first review. The only request was to provide more motivating examples. I am going to provide R1 soon. If you have any interesting use cases please let me know.

[JadeMatrix]

@mpusz That's great to hear, I was surprised when I found out it wasn't already supported. You use a template bool in the proposal; would a more general form look like this?

template< template< typename > auto TVar >

Also, do you know if any compiler has implemented this as a 23 preview feature?

[mpusz]

bool is just an example. Basically, it should take any type that NTTP can take. So yes, auto should also work.

It is not a 23 preview featured yet. It was even not discussed in Evolution WG so far. First, it has to be accepted by the C++ Committee. To help it succeed I need cool usage examples ;-)

[mpusz]

FYI: I plan to work to address all the issues discussed soon. The only problem is that I have too many things on my plate lately, but I hope to have time for it in March.

[chiphogg]

Hi! I'm a SWE at Aurora Innovation, and a units library enthusiast. 🙂 I'd like to share some details about how we've solved this problem in our units library, both in the hope that it's useful (a std::units library really should support degrees), and to get any technical feedback.

A little while after we landed the library, I found this comment from @burnpanck, which came the closest to our solution of anything I've seen anywhere. The main similarities are:

• Represent irrational scale factors by types, to perform exact symbolic computation. Call these "basis factors", and let users take arbitrary rational powers of them.
• Associate each such "basis factor" type with a corresponding value, to help in performing the actual conversions. (In our implementation, the value also helps with canonicalization. @burnpanck identified the need for canonicalization, but it wasn't clear to me if it was intended to be based on the value, or something else.)

The main differences are:

• We use prime factorizations (easy to compute at compile time) for the rational part, instead of Num and Denom. This helps us scale much better (for example, we still support basis factors up to std::intmax_t, but we automatically also support powers of them up to std::intmax_t). It makes canonicalization trivial, as we'll see below, by treating all basis factors (i.e., both prime numbers, and irrational constants) on an even footing. Finally, It also makes our Scale representation into a vector space over the rationals, which is mathematically kind of neat. 🤓
• We don't propose to use a concept; instead, we use a template Scale<...> with a variadic pack of "basis powers" (i.e., powers of basis factors). Using a variadic pack, as opposed to a concept, lets us effortlessly adapt to use any number of basis vectors from the infinite-dimensional vector space of our representation. It also should let us support standards as far back as C++14 (although given this library's C++26 target, that's not as much a consideration here).

Here's a basic example (adapted slightly for this format):

// Convenient shorthand, to aid in understanding what follows:
template <std::intmax_t N = 1>
using Pi = BasePower<ConstPi, N>;

// An example of defining a relatively scaled unit in our library.
using Degrees = scale_unit<Radians, product_t<Scale<Pi<>>, ratio_t<1, 180>>>;

The relative scale factor for this unit would expand out to something like the following:

Scale<BasePower<Int<2>, -2>, BasePower<Int<3>, -2>, BasePower<ConstPi, 1>, BasePower<Int<5>, -1>>

(Yes, the exponents are integers for now. While we plan to support rational exponents, we haven't found the need yet; the library is pretty new.)

Notice that the basis factors (i.e., prime numbers, and irrational constants) are naturally sortable (because irrationals are an ordered field extension of the rationals), which gives them an unambiguous canonical ordering. Or, more directly: Pi goes after 3 and before 5. This canonicalization is necessary to keep the Scale factors (i.e., positive real numbers) 1:1 with the types. Two other things that are important for this canonicalization:

• Base powers with an exponent of zero are omitted.
• Basis factors are independent (i.e., no basis factor can be expressed as a product of rational powers of any other basis factor).

One natural worry with this approach would be the compile time cost of the variadic pack. So, we measured. We created "adversarial" units with over 20 different basis factors, and made repeated measurements on some units-heavy code. We did observe a slowdown, but it wasn't subjectively noticeable; and, it was basically equivalent to running the nholthaus library on the same code, but with almost all of its units stripped out. So, in practice, performance really does not seem to be a concern.

Another worry is that the types can get pretty long. It's true that representing 180 by its prime factorization is a little counter-intuitive for the reader of the compiler errors. 🙂 That said, the excellent downcasting facility should completely hide the scale factors from the end user for every named unit.

One nice strength is the separation between the symbolic computation, and the actual conversion process. Every conversion is based on a single Scale type. So you could make a type trait, Converter<ScaleT, T, OutputT=T>::convert(T x) with a suitable default implementation, and then specialized appropriately for whatever use cases you want to tune. (e.g., purely integer multiples, purely rational numbers, very large factors beyond std::intmax_t, etc..). And these tunings can be invisible to end users, too.

Those are the basic ideas of our solution for Scale factors. If you adopted something like this, you could immediately support Degrees, and also remove the custom solution you have for powers of 10 beyond the reach of std::intmax_t (such as yotta). That said, your design constraints may be different from ours. Let me know what you think; I hope something in here will be useful to you!

[burnpanck]

I think this could be a very useful implementation for these symbolic prefactors. The prime-factorisation may seem unwieldy and various other approaches are conceivable, e.g. keeping a "standard intmax ratio" prefactor or allowing non-prime factors with a preference e.g. for 10, which would potentially make the Scale template shorter in common cases, but would make canonicalisation more difficult. Thus, prime factors may well prove the simplest implementation because of that.

In any case, the upshot is that both the "base unit" and the "scale" of a composite quantity is well represented as product of powers of symbolic factors. If these products can be canonicalised, then a simple variadic template provides a type identity that matches equality of the represented values, a property we need both for the "base unit" and the "scale". If the symbolic factors are "irreducible" (none can be expressed as a product of powers of the others), then any total order of the symbolic factors provide such a canonicalisation.

As a small side: Contrary to the prime factorisation of integers, I believe generic irrational numbers cannot be canonically decomposed into "irreducible" factors. That is, e.g. both "π" and "2π" (or even "πe") are perfectly valid irrational numbers which could be used in such Scale type. It will therefore up to the designer of the unit system not to include irrationals which are products of each other. That is unlikely to be a problem, given that a typical unit system will have at most a handful of symbolic irrationals.

[chiphogg]

Thanks for this comment. I think basically everything you've said here is spot on.

For the problem you mention in the third paragraph, we can resolve this ambiguity by preferring to introduce constants that have widely recognized symbolic names. For example, when introducing degrees to complement an existing radian unit, we would choose "π" as our new "basis factor", even though "180/π" would be in some sense more direct for this use case. This also means that if we had a unit with a factor of "πe", we would introduce two new basis factors, "π" and "e". This policy makes it easier for end users to interpret our factors.

[i-ky]

I have a technical remark. Instead of saying "irrational" we should say "transcendental", because there are irrational numbers that can be represented as a rational number raised to a rational power, e.g. irrational √2 is rational 2 raised to the rational power of ½. Such irrational number cannot serve as basis factor, because it will introduce ambiguity in representation of certain factors.

Transcendental factor, e.g. π or ⅇ, can be a basic factor, because when raised to a rational power it stays transcendental and therefore does not "interfere" with prime factorization of factor's "rational part". Powers of basis factors will still uniquely describe the factor.

However, having more than one transcendental basis factor may be problematic, because multiplication/division of two transcendental numbers may yield a rational number, e.g. both π and τ are transcendental, but τ/π=2 is rational. Who knows, maybe even π×ⅇ turns out to be rational...

Luckily, we only need one transcendental basis factor and it should be our very special π. Or equally special τ ;)

[chiphogg]

As I've had more time to digest this problem subconsciously, it's dawned on me that the case for a vector space representation, rather than ratio, is stronger than I initially recognized.

The initial post in this discussion lists and compares some potential solutions for Magnitude. I think we should start by carefully defining our criteria first. What properties do we need in a good representation for the "Magnitude" component of a unit?

First: what is a Magnitude? It's a positive real number. So we are choosing a representation of positive real numbers. Here are some properties I think are important for this representation:

• Operation support. It must support all the operations we perform on Units. These are the same as for the Dimension component: products, quotients, and arbitrary rational powers.
• Exact symbolic computation. If we pick up a factor of, say, π, and it later cancels out, it must cancel cleanly and completely.
• Avoid multiple representations. Each real number we represent must have one unique representation.

Having made our criteria explicit, it becomes clear that a "ratio" performs poorly as a Magnitude representation.

• It cannot represent irrational factors (the problem which kicked off this discussion).
• Rational numbers are, rather famously, not closed under rational powers. Thus, even the Magnitudes we can represent as ratios do not support the basic operations they need to (!). I think it's important to appreciate this point.
• The numerator/denominator representation is vulnerable to overflow.
• It may be tempting to try working around the lack of irrational numbers by using rational approximations (e.g., 314159/100000). (I think boost units takes this approach?) Not only would this destroy the ability to do exact symbolic math; but, the better we make our approximation, the worse we make the overflow problem.

"Ratio" is just not the right concept for this.

By contrast, a vector space over the rational numbers is a really nice fit, because as @burnpanck pointed out above, it's the exact same representation that we already use for Dimension. This means we automatically and naturally support all the same operations. The main challenge was in figuring out the basis factors, but we solved this by recognizing that prime numbers are "linearly independent" from the perspective of the vector space. Other irrational factors are as easy as adding a new basis factor. The overflow problem all but disappears.

By these criteria, the vector space approach is a complete solution, while the ratio approach appears to be more of a dead end (due to not supporting rational powers) than I had at first appreciated.

[chiphogg]

I have a technical remark. Instead of saying "irrational" we should say "transcendental", because there are irrational numbers that can be represented as a rational number raised to a rational power, e.g. irrational √2 is rational 2 raised to the rational power of ½. Such irrational number cannot serve as basis factor, because it will introduce ambiguity in representation of certain factors.

Transcendental factor, e.g. π or ⅇ, can be a basic factor, because when raised to a rational power it stays transcendental and therefore does not "interfere" with prime factorization of factor's "rational part". Powers of basis factors will still uniquely describe the factor.

However, having more than one transcendental basis factor may be problematic, because multiplication/division of two transcendental numbers may yield a rational number, e.g. both π and τ are transcendental, but τ/π=2 is rational. Who knows, maybe even π×ⅇ turns out to be rational...

It's not often appreciated that certain "obvious" transcendental numbers, such as "π×ⅇ", are not even known to be transcendental at all. Certainly this fact threw me for a loop when I first learned it!

I've given the practical implications of this conundrum quite a bit of thought. I've concluded that it doesn't actually matter for software applications. Suppose π×ⅇ turned out to be equal to some product of rational powers of primes. Undoubtedly, that combination would be pretty obscure and complicated, or else it would already have been discovered. As long as a human would consider these numbers to be distinct, then it's fine to treat them as separate in the application as well, because it would keep our representation more recognizable.

Luckily, we only need one transcendental basis factor and it should be our very special π. Or equally special τ ;)

😁

[chiphogg]

For posterity's sake, and discoverability, my understanding is that #300 will definitively resolve this discussion. If anyone disagrees, or if I've missed anything, feel free to chime in here. Otherwise, consider upvoting this comment for visibility.

[mpusz]

Implemented with 8b534c8

[JohelEGP]

So, can this be closed?