A units library should be specified in terms of concepts

[kwikius]

mp_units uses a singe template type quantity. but there is another way. Make quantity a concept and provide operations that work on any valid model of quantity.

The advantage is that existing types that model the concepts can be reused with out abi modifications, while working seamlessly with the library.

An example of how existing types can be reused in this way is std::chrono::duration

With the concept based approach std::chrono::duration is a valid quantity
Sample pqs syntax involving chronos::duration and pqs quantiies

static_assert(1s + 1q_s == 2q_s);

In mpunits The chrono::duration must first be converted ,using the already overused explicit conversion syntax, to the mpunits quantity type before it will work with the library
The same expressed in mpusz syntax

static_assert(quantity{1s} + 1_q_s == 2_q_s);

A basic set of concepts for the concepts based approach is documented here

The C++ implementation is here

[mpusz]

OK, so I can write a Quantity concept that will match units::quantity, boost::quantity, benri::quantity, std::chrono::duration, and a few more libraries). Then, I can write a generic:

Quantity auto operator+(Quantity auto lhs, Quantity auto rhs);

The first problem is what should be the result of units::time + std::chrono::duration. We discussed this some time ago and you suggested returning units::quantity as the only viable type, right? It is getting even more strange when we consider boost::time + std::chrono::duration -> units::quantity. But it somehow works...

But now, other libraries do the same (i.e. pqs defined it already). I hope you implemented it exactly token-wise the same as I did in mp-units and you also return units::quantity in pqs for this operation. Otherwise, we have ambiguous overloads or the ODR violation. 😉

[kwikius]

OK, so I can write a Quantity concept that will match units::quantity, boost::quantity, benri::quantity, std::chrono::duration, and a few more libraries). Then, I can write a generic:

Quantity auto operator+(Quantity auto lhs, Quantity auto rhs);

The first problem is what should be the result of units::time + std::chrono::duration. We discussed this some time ago and you suggested returning units::quantity as the only viable type, right? It is getting even more strange when we consider boost::time + std::chrono::duration -> units::quantity. But it somehow works...

As you have shown the two external libraries operations will ( depending on the operation) by default output a library type if the two libraries opt in to being models of quantity. It doesn't usually know about your types. An exception may be q+q which returns a q type, but you already wrote that right?

But now, other libraries do the same (i.e. pqs defined it already). I hope you implemented it exactly token-wise the same as I did in mp-units and you also return units::quantity in pqs for this operation. Otherwise, we have ambiguous overloads or the ODR violation. wink

You can remove an operation by specialising the provide_operator<Qa, Op, Qb> (where Op is some operation, such as plus, minus, times etc) to return false and then this operation on those types will not be considered in the overload set.
https://github.com/kwikius/pqs/wiki/concept-quantity#provides.

You can also specialise the semantic operation itself since it is a template type : https://github.com/kwikius/pqs/blob/6369f4e57310bfde733cda5047a486e641fc9e68/src/include/pqs/concepts/quantity/plus.hpp#L19

... so you can write your own operations with their own semantic if you wish.

[JohelEGP]

Looks interesting. But it'd be on the user to solve the ambiguity problems between libraries. The standard would have you require that such specialization depend on a program-defined type. Otherwise, you risk two users independently specializing such a template with the same parameters and yet not be exactly the same. That runs afoul of some language rules that trigger ODR or some such.

[kwikius]

I hope I will get time to work on that maybe using my quan librray and mpusz_units, but this post shows a much more exciting use for the concept based approach;

To hide implementation details so that user that want it can have a very simple units interface

[mpusz]

You can remove an operation by specialising the provide_operator<Qa, Op, Qb> (where Op is some operation, such as plus, minus, times etc) to return false and then this operation on those types will not be considered in the overload set.

Who should be responsible to provide those? A library author or a user?

If the author, then which library should disable it, mp-units or pqs? Are you going to do the same for benri, boost, and other libraries too right away? A user may choose to have all of them in their project, right? As you can see there are many issues here, starting from the fact that you have to include benri's, boost's, and headers of other libraries in pqs in order to be able to disable them.

If the user, then it is not going to work. A user is not allowed to add any new types or functions to the std namespace and it should be also true for other libraries. So instead of just = delete for a function template you should provide a type trait to enable such a functionality (a user is allowed to provide specializations of a class or variable template in std for its own types`).

Now, no matter which one you chose above you make it work for libA. For example, libA will disable op+ in pqs. But there might be a libB that will disable the op+ in mp-units. Now we have libC that want to use libA and libB...

[kwikius]

The discussion about problems with the conversion factor being a rational number to a base10 exponent #195 throws up another issue. The conversion factor should be a concept. The Concept should specify what is required, presumably some compile time evaluable function to convert a value in unit A to a value in unit B, but shouldn't specify any implementation details as to how it should be done. Requiring the conversion factor to be a mpusz ratio type is over specifying it. #187 (comment). which limits extensibility

FWIW my own library makes this error currently as well. https://github.com/kwikius/pqs/wiki/type_template-conversion_factor

[mpusz]

As I stated already here I considered such an option but it has also many issues. Ratio arithmetic is hard. If you do not believe me see here:

• https://github.com/mpusz/units/blob/master/src/include/units/ratio.h
• https://github.com/mpusz/units/blob/master/src/include/units/bits/ratio_maths.h
  and this is only for a one fixed type. If we introduce more (i.e. Irrational conversion factors: planar angle and π #195 (comment)) then we will have to define what op+(ratioA + ratioB) means. If the user will provide its own type it will explode pretty fast to provide operators support for every possible combination of those types.

[kwikius]

Type explosion was cited as a reason for keeping everything in base units by Walter Brown once upon a time . There is a paper about it on WG21 I believe. conversion factors are compile time only entities. These days compilers can cope.

hard wiring one (template for lawyers) type you kill any chance of extensibility. Therefore I think it s necessary to provide a conversion factor concept. The units::ratio could, one would hope, be useful to implement some library model of the concept!

Let us discuss the actual minimal requirements

Let the unit system be s
Let qB be a quantity comprised of base_units of s
let vB be the numeric value of qB

Let qX be some quantity in s in incoherent units
Let vX be the numeric value of qX
Let kX be the conversion factor to convert vX to vB

vB = vX * kX

Let qY be some quantity in s in incoherent units
Let vY be the numeric value of qY
Let kY be the conversion factor to convert vY to vB

vB = vY * kY

therefore

vX * kX = vY * kY

therefore

vY = vX * (kX / kY)

So the conversion factor needs to support

• compile time division of conversion factors by each other (resulting in a valid conversion factor)
• Maybe compile time multiplication of conversion factors by each other (resulting in a valid conversion factor). Not required here but may be required?
• runtime multiplication of the underlying Reptype by a conversion factor.
• (Probably conversion factors also need to be compile time totally ordered)

I don't think there is a requirement for compile time addition and subtraction of conversion factors?

[mpusz]

As said, I think it is a good idea to provide such a concept but was of a low priority so far. I still think it is a low priority because I would love to find a solution that would work for angles with one units::ratio type rather than already being forced to define a few of them and provide interop between them.

Anyway, it might be a bit bigger and more tricky than mentioned above:

1. It should probably be at least semi-regular (but I would prefer regular).
2. What should be the result of 1000 * ratio{1}? According to "runtime multiplication of the underlying Reptype by a conversion factor." I believe that you would like the result of this to be 1000. However, I think it should be the ratio(1000) (kilo() said otherwise).
3. I think that non-member function convert(1000, ratio{1}) (or a similar name) should be provided to execute the conversion operation and get 1000.
4. Compile-time multiplication is a must (we already multiply ratios a lot in our library).
5. We found a few cases when an explicit inverse() operation is useful.
6. pow non-member function template should be provided:

template<std::intmax_t Num, std::intmax_t Den = 1>
  requires detail::non_zero<Den>
[[nodiscard]] constexpr ratio pow(const ratio& r)

7. common_ratio() non-member function has to be provided as well
8. In case more than one ratio type will be involved in a calculation op*, op/, and common_ratio has to be provided for a pair of ratio types in both argument orders. So it requires another concept (i.e. RatioWith<R1, R2>) to check if those are supported as well.
9. It seems that we also need [[nodiscard]] constexpr bool is_integral(const ratio& r)