ISO 80000-1:2009(E)

• Quantity for which all the exponents of the factors corresponding to the base quantities in its quantity dimension are zero.
• The measurement units and values of quantities of dimension one are numbers, but such quantities convey more information than a number.
• Some quantities of dimension one are defined as the ratios of two quantities of the same kind.

Assuming:

auto q1 = quantity<metre, double>() / quantity<metre, double>();
auto q2 = quantity<second, double>() / quantity<second, double>();

What the result should be?

(please vote only once by clicking on the correct bar above)

• Option 1 (current library design)

  static_assert(std::is_same_v<q1, double>);
  static_assert(std::is_same_v<q2, double>);
  auto q = q1 + q2;
  static_assert(std::is_same_v<q, double>);
  

• Option 2

  static_assert(std::is_same_v<q1::dimension, dimension<>>);
  static_assert(std::is_same_v<q2::dimension, dimension<>>);
  auto q = q1 + q2;
  static_assert(std::is_same_v<q::dimension, dimension<>>);
  

• Option 3

  static_assert(std::is_same_v<q1::dimension, dimension<exp<base_dim_length, 0>>>);
  static_assert(std::is_same_v<q2::dimension, dimension<exp<base_dim_time, 0>>>);
  // auto q = q1 + q2;  // does not compile
  

  Please note that in such a case:

  auto q1 = 10mps * 2s;     // length
  auto q2 = q1 / 2m;        // dimensionless<length>
  auto q = 10mps * 2s / 2m; // dimensionless<velocity>
  

Q: What are the minimum requirements for a standard units library?

A: Modelling the S.I. system as closely as possible. The way that is implemented is not really relevant. The S.I is a global standard.

Problem: Unfortunately the general user has no voice on the c++ committee.

I worked on a quantity /units library for boost since way back in 2003. I need a library that modelled S.I units.

My original problem was that I was working on an app to design small wind turbines, using doubles for quantities and getting fed up with checking what units each variable was in, which wasted a lot of time. The library I wrote later solved that issue very nicely. All Si units.

I see that @mpusz started around the same place except for working on a gliding app. All SI units. https://github.com/mpusz/Condor2Nav I understand the motive exactly.

Again engineering, not Theoretical Physics. All S.I. Units.

The library that can (apparently) do all that that Theoretical Phyiscists want is now in Boost but what was created there didn't actually elegantly answer a problem for which there was a general need to be solved - modelling the SI. For the general user, Boost.Units it is way to cumbersome and hard to understand and use. It is time to tell the Physicists to go away and fix their Units library on Boost and to produce their own globally recognised standard, before we spend more of the general users time arguing about their exotic needs.

That theme of a Physicists making impossible demands about their "essential needs" then disappearing once they are met needs to be remembered. General users need SI units more than they need Natural units. Remember there is no global standard for Natural units. Each physicist enjoys showing why their own version is superior. A library for the general user just doesn't need to support that. And we dont have time to argue about it.

mp-units should drastically limit its scope so that it caters for the average user who uses SI units, not "smart people", language lawyers or physicists, else there is no way it will or should get in to the C++ standard. What is left will be easier to maintain and certainly more likely to write standard documentation for.

It would be great if mp_units was a general framework but in practise the minimum is that there needs to be the ability to work with SI quantities, that is simple and intuitive to use. Ultimately the standard is about the interface not the implementation.

It is time to pare away the std units candidate to the bare minimum requirements

Just model the SI system, following the docs as closely as possible ( so no angle as dimension for example). Stick to same Rep concept as std::chronos::duration. If anyone complains that the Rep type is no good, tell them to provide a solution fixing it for chrono duration.

This PR doesn't aim to convert every last use case. Rather, the goal is to perform the smallest "reasonable" change such that the repo still builds.

We bundle a few auxiliary changes which could have been separate PRs, but which I included here to reduce the total time-to-land. To reduce reviewers' cognitive load, I've retained them as separate "checkpoint commits". Reviewers can start at the first commit and step through for ease of reading. These auxiliary changes include:

• Supporting subtraction and spaceship operators in ratio

• Implementing the "common Magnitude" functionality, which is equivalent to the "largest even divisor" logic we've borrowed from std::chrono in every applicable case, but which is simpler for Magnitudes

• Loosening the requirements on the Rep of a Magnitude, which is necessary to maintain support for non-is_arithmetic Reps. NOTE: there is some remaining work here to express everything in terms of treat_as_floating_point, which we can either do in this PR, or later, as reviewers prefer.

The "bulk" of the PR simply performs fairly mechanical migrations from ratio to as_magnitude<ratio>() in various template arguments. Some corner cases and concepts (e.g., UnitRatio) simply melt away, because we don't need them in a Magnitude-based world. The only "asterisk" in this migration is a few test cases in the formatting, where the current implementation produces an equivalent but different representation. I've commented these out, and we can deal with them later.

Follow-on work includes:

• Hunting down remaining uses of ratio in template arguments
• Removing exp
• Making degrees and revolutions for angle units

Partially addresses #300.

Dear Mr. Mateusz Pusz,

Much of C++ template programming with C++20 features is still a bit overwhelming for me at this point in time.

I do not fully understand how the library is written, but I can rely on what I already know about it and my intuition to understand certain parts. I think I get the gist of it.

I am using this library for SPICE circuit generation using custom templates. I have generator classes that are responsible for rendering the custom templates into SPICE circuit text.

Initializing my generator: RCCircuitGenerator generator {5ns, 2ms, 5V, 1ms, 10kR, 10nF};

The formatting string for the line starting with "RLOAD" (see below) looks like this: RLOAD 1 2 {:%Q%q}

The following SPICE RC circuit text would be generated:

RC_CIRCUIT
.TRAN 5ns 2ms
VSRC 1 0 PULSE 0 5V 0 0 0 1ms
RLOAD 1 2 10kΩ
CCHARGE 2 0 10nF
.END

However, the SPICE simulator library I am using, ngspice, expect ASCII encoding. The simulation crashes when this circuit is passed to the library.

With the changes I have provided, when the formatting string for the line starting with "RLOAD" looks like this: RLOAD 1 2 {:%Q%a}

Then the following SPICE RC circuit text would be generated:

RC_CIRCUIT
.TRAN 5ns 2ms
VSRC 1 0 PULSE 0 5V 0 0 0 1ms
RLOAD 1 2 10kohm
CCHARGE 2 0 10nF
.END

And the SPICE simulation then works.

I hope that my modifications adhere to the style and philosophy of this library as closely as possible.

Please let me know of any modifications you would like to me perform first if you would like to merge this pull request eventually.

Thank you very much.

Ramzi Sabra

Raise coherent quantity to fractional power doesnt give correct result. Personally I am not so bothered about incoherent quantities but for coherent quantities this can be done better.

Currently doesnt give the correct answer:

https://godbolt.org/z/6bgkEK

For coherent quantities the multiplier of the result should remain as one ,and the exponent should be adjusted ( so for square root divide exponent by 2, and in fact for pow<R>(q) the result exponent is simply multiply the exponent by R ( so for square root multiply by 1/2, for cube 1/3, for pow<3/2> multiply by 3/2. If the exponent is a rational number then it can represent the quantity raised to fractional power correctly and exactly .

Hidden Friends are good because they help with overload resolution and thus are suggested for usage in a modern C++ design.

However, for quantity it produces issues with implicit conversions. The second assert of the following code compiles fine even though it shouldn't: https://godbolt.org/z/kSrqHT.

When non-friend version is used it correctly fails to compile: https://godbolt.org/z/32s4cj

We could provide template parameters for both arguments of a hidden friend implementation: https://godbolt.org/z/2uMsPB. However, in this case we end up with an ambiguous overload set. So we have to constrain it: https://godbolt.org/z/RKaopR. With this, we achieved what we wanted but with a cost of a more complicated signature.

Should we provide constrained hidden friend version of the operator or non-friend one with all its overload resolution issues?

The 'units::Scalar' concept definition has nothing to do with any external definition of scalar and is very misleading, https://github.com/mpusz/units/blob/master/src/include/units/quantity.h#L63 should be renamed to RegularNotQuantity or something similar especially since Vector is an allowed rep type https://github.com/mpusz/units/blob/master/example/linear_algebra.cpp#L205

std::chrono is based on the difference between a point on the time dimension (time_point) and the difference between two such points, a quantity (a duration for the time dimension).

Do you plan to add such a dimension-point in your library?

I am working on a bare metal ARM-cortex M project using this units library.

I just updated to the head of your main branch and changes in src/core/include/units/magnitude.h are causing compilation errors. Specifically the use of throw statements. I have it working now by guarding each throw with the macro

#if __has_feature(cxx_exceptions) || defined(__cpp_exceptions) || \
    (defined(_MSC_VER) && defined(_CPPUNWIND)) || \
    defined(__EXCEPTIONS)

EDIT: I think this may not be related to -fno-exceptions, since it does compile if I make some small code changes. I am trying to fins the root cause and will update/close issue when I find out more (see my comments below).

Compiler: arm-none-eabi-11.3.1-rel1 (latest ARM provided toolchain) arch: ARM-v8M-baseline (M23)

We provide two new functions, numerator(m) and denominator(m), for a Magnitude m. They fulfill the following conditions:

1. numerator(m) and denominator(m) are always integer Magnitudes.
2. If m is rational, then m == numerator(m) / denominator(m).

If m is not rational, then the numerator and denominator are not especially meaningful (there is no uniquely defined "leftover irrational part"). However, we choose a convention that matches how humans would write a mixed number. For example, sqrt(27/16) would have a numerator of 3, denominator of 4, and a "leftover part" of sqrt(3), matching the "human" way of writing this as [(3 * sqrt(3)) / 4]. This has no use yet, but it may later be useful in printing the Magnitude of an anonymous Unit for end users.

To further reduce friction for the upcoming migration, we provide a conversion from a Magnitude to a ratio. We restrict this operation to rational Magnitudes, and guard this with a static_assert.

This is the beginning of the implementation for #300, laying the first foundations. This seems like a good point to check in and align on direction before we get too far along. For general context:

Things we include here:

• Concepts for Magnitude, and BasePower (a Magnitude is made up of a canonicalized parameter pack of BasePowers).
• End user interfaces for making magnitudes:
  • as_magnitude<ratio>(): the main way to make a Magnitude from a rational number. This handles the "heavy lifting" of converting to a prime factorization.
  • base_power<T>{ratio}: we handle irrational bases by introducing a type T, with a static long double member value which must be positive.
• Enhanced ratio functionality: addition, negation, and implicit construction.

Work yet undone:

• A mechanism for applying a magnitude to a given value. (We'll probably want to break out the rational and irrational parts separately, so we can give exact results as often as possible. We'll also want to think carefully about what types we use in intermediate computations---for example, not everyone will want to use long double, and even double can be problematic for some embedded applications.)
• Actually migrating existing uses to use Magnitude instead of ratio.

Once we get to something that looks like the right direction, I can flesh out these other items.

Today, after a code review comment, I added a second syntax that creates a quantity in V2 design:

static_assert(120 * isq::distance[km] / (2 * isq::duration[h]) == 60 * isq::speed[km / h]);  // #1
static_assert(isq::distance(120, km) / isq::duration(2, h) == isq::speed(60, km / h));       // #2

You can find diff with more examples here: https://github.com/mpusz/units/pull/391/commits/858cbb472fe320fdb648fb976f5f026145ba8009.

For now, we have two of those, but I would like to decide which one is better ASAP and remove the other one. Please review the above commit and share your opinion.

As @JohelEGP noticed in https://github.com/mpusz/units/issues/411#issuecomment-1362809717, current accessors remove all encapsulation. Should we remove lvalue overload so the only remaining would be:

  [[nodiscard]] constexpr const rep& number() const& noexcept { return number_; }
  [[nodiscard]] constexpr rep&& number() && noexcept { return std::move(number_); }
  [[nodiscard]] constexpr const rep&& number() const&& noexcept { return std::move(number_); }

Structural types are the types that can be used as NTTPs. quantity and quantity_point do not satisfy a current definition of a structural type as it requires a class to have public data members. This means that we cannot put them in template parameters which could be really handy in some cases.

Should we make a data member public (at least until the C++ language will not extend the definition to allow private members as well)?

With the new design a following change was needed:

using state = kalman::state<quantity<isq::position_vector[m]>, quantity<isq::velocity[m / s]>>;
-const state initial = {30 * km, 40 * (m / s)};
+const state initial = {30 * isq::position_vector[km], 40 * isq::velocity[m / s]};

As @JohelEGP correctly noticed that:

seems like an unfortunate deviation from the general idea of ISO 80000-1, 7.1.4 “Expression for quantities” and 7.2 “Names and symbols for units”'s 7.2.1 “General”. Since state is already strongly typed, could the previous iterator be made to work? I think it's preferable if C++ code looked like the quantity expression. Strong typing could be added without affecting it.

The intention seems to be for "30 km" to not be decorated with anything other than the number and the unit. In C++, we use * out of necessity. But this shouldn't be the place to specify the quantity.

I was thinking of permitting x * km, where x is a function parameter, to initialize any quantity of dimension L (besides the requirements on the representation and the unit).

Discussion of alternatives

A number and a unit are not enough to define a quantity. Even adding a dimension was found to be deficient. This was one of the biggest issues with the old "references".

Regarding function parameters, I am not the biggest fan of this syntax in general. Consider:

void foo(double a, double b)
{
  quantity<isq::distance[km]> l = a * m;
  quantity<isq::duration[h]> d = b * s;
  quantity<isq::speed<km / h>> speed = l / d;
}

This looks really cryptic to me and might be a source of confusion. I would much prefer people to type:

void foo(double a, double b)
{
  auto l = a * isq::distance[m];
  auto d = b * isq::duration[s];
  quantity<isq::speed<km / h>> speed = l / d;
}

So I do not think that there is a problem here. Additionally, to support such a scenario, we will have to introduce yet another type/abstraction that would handle such a scenario and make a quantity implicitly constructible from it. I am not so sure if it is worth it.

Another point here worth considering is that right now, we do the following to define a scaled unit:

inline constexpr struct minute : named_unit<"min", mag<60> * second> {} minute;

and I hope that if expression aliases became a part of the C++ language, we will write:

inline constexpr struct minute : named_unit<"min", 60 * second> {} minute;

so a 60 * s is just yet another scaled unit and not a quantity value.

Proposed solution

However, there is another even simpler solution to the problem. For now, the quantity cannot be implicitly constructible from the representation type, so we cannot just leave numbers to initialize the struct.

I believe that the creation of quantities from raw number arguments is quite rare and happens only on the boundaries of strongly typed engines. On the other hand, the initialization of some quantities from constant values will happen quite often, and sometimes, a quantity will be packed inside of the aggregate. Until now, we were not able to initialize such aggregates in an efficient way, and now with the V2 design it looks like this:

quantity<isq::length[m]> vec[3] = { 1 * isq::length[m], 2 * isq::length[m], 3 * isq::length[m] };
std::tuple<quantity<isq::length[m]>, quantity<isq::time[s]>> t = { 1 * isq::length[m], 1 * isq::time[s] };

If we would make the constructor implicit, then the above could be rewritten as:

quantity<isq::length[m]> vec[3] = { 1, 2, 3 };
std::tuple<quantity<isq::length[m]>, quantity<isq::time[s]>> t = { 1, 1 };

which I think could be a big improvement here.

On the other hand, it would allow something like:

void foo(quantity<isq::length[m]>);

int main()
{
  foo(3);
}

which I am not so sure if it is a great idea, although I am ready to discuss and consider it.

Any ideas, thoughts, or comments are welcome here.

Acceleration is a change of velocity over time (a = V / t). Acceleration and velocity are defined as vector quantities, whereas time is scalar.

If I want to calculate t = V / a, it is impossible if representation types of a and V are linear algebra vectors as it is impossible to divide two vectors. Additionally, the characteristics of a derived quantity of velocity divided by acceleration is vector as well so it will not allow assigning to a scalar time.

This is a simple and common case but also so complicated now after #405. How to handle that?

Consider providing a partial specialization for std::numeric_limits to provide all the numeric properties of underlying representation types. Remove min() and max() from quantity and also remove standalone epsilon() from math.h.

The only problem is what to do with the remaining zero() and one() as those are not provided via std::numeric_limits.