Reevalute the use of the downcasting facility on units

[JohelEGP]

The use of the downcasting facility on units is at odds with

It is therefore important not to use the unit alone to specify the quantity. This applies not only to
technical texts, but also, for example, to measuring instruments (i.e. the instrument read-out
needs to indicate both the unit and the quantity measured).
-- Extract from https://www.bipm.org/en/publications/si-brochure

This is quoted at #32 (comment). I do not think the library should, for example, transform an unit of s⁻¹ to Hz. That conversion should be explicitly specified by the user where it matters, because they carry different information.

Dropping the use of downcasting facility on units will also remove the source of conflicts between equivalent units that currently want to be downcasted to from the same set of base units.

[mpusz]

Yes, I seriously thinking about removing this feature from the library. It is great when it works, but it cannot cover all the bases and is really a pain in the xxxx when it doesn't do what is expected.

Said that we are facing a huge library redesign as the library was built around this facility being a primary feature. It should not affect the entity definitions (units, dimensions, ...) too much but will totally change how the framework works under the hood.

Right now when we divide length by time the framework generates something like:

quantity<detail::derived_dimension_base<exponent<dim_length, 1>, exponent<dim_time, -1>>, scaled_unit<ratio(1, 36, 1), unknown_coherent_unit<exponent<dim_length, 1>, exponent<dim_time, -1>>>, double>;

which is converted to either strong types with the downcasting facility or end up as:

quantity<unknown_dimension<exponent<dim_length, 1>, exponent<dim_time, -1>>, scaled_unit<ratio(1, 36, 1), unknown_coherent_unit<exponent<dim_length, 1>, exponent<dim_time, -1>>>, double>;

That was caused by the fact that we had to have a deterministic base class type that is a unique identifier for the downcasting operation. Now we do not have such constraints, so we can generate something like:

quantity<dimension<dim_length, pow<dim_time, -1>>, unit<kilometre, pow<hour, -1>>, double>;

or even

quantity<dimension<dim_length, per<dim_time>>, unit<kilometre, per<hour>>, double>;

The above is much easier to read and understand. It should also allow us to print quite nice text output on the console, even for unknown quantities. Such a result should be implicitly convertible to a user-predefined strong type.

Everyone, do you have any ideas, comments, or wishes? 😉

[JohelEGP]

Everyone, do you have any ideas, comments, or wishes? wink

I'm working on something with Clang's C++ modules: https://godbolt.org/z/8abY1E8vq.

<source>:1500: undefined reference to `f(waarudo::quantity<waarudo::_unit<&waarudo::frame, &waarudo::per, &waarudo::second>::v, unsigned int>)'
<source>:1477:3: error: no matching function for call to object of type '(lambda at <source>:1473:12)'
  g(pge_frames_per_second{});
  ^
<source>:1473:12: note: candidate function not viable: no known conversion from 'quantity<v, unsigned int>' to 'quantity<metre, int>' for 1st argument
  auto g = [](decltype(m)) {};
           ^
<source>:1473:12: note: conversion candidate of type 'void (*)(decltype(m))' (aka 'void (*)(quantity<metre, int>)')
<source>:1478:29: error: invalid operands to binary expression ('pge_frames_per_second' (aka 'quantity<_unit<&frame, &per, &second>::v, unsigned int>') and 'quantity<metre, int>')
  (pge_frames_per_second{}) + m;
  ~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~
<source>:868:61: note: candidate template ignored: could not match 'v' against 'metre'
  [[nodiscard]] constexpr quantity<R, decltype(N{} + N2{})> operator+(const quantity<R, N2>& r) const {
                                                            ^
<source>:1474:28: error: invalid operands to binary expression ('waarudo::quantity<waarudo::_unit<&waarudo::frame, &waarudo::per, &waarudo::second>::v, unsigned int>' and 'quantity<metre, int>')
  auto h = [&](auto v) { v + m; };
                         ~ ^ ~
<source>:1479:4: note: in instantiation of function template specialization 'waarudo::f()::(anonymous class)::operator()<waarudo::quantity<waarudo::_unit<&waarudo::frame, &waarudo::per, &waarudo::second>::v, unsigned int>>' requested here
  h(pge_frames_per_second{});
   ^
<source>:868:61: note: candidate template ignored: could not match 'v' against 'metre'
  [[nodiscard]] constexpr quantity<R, decltype(N{} + N2{})> operator+(const quantity<R, N2>& r) const {
                                                            ^
<source>:1480:3: error: invalid argument type 'waarudo::quantity<waarudo::_unit<&waarudo::frame, &waarudo::per, &waarudo::second>::v, unsigned int>' to unary expression
  ~std::identity{}(pge_frames_per_second{});
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<source>:1482:3: error: invalid argument type 'pge_frames_per_second' (aka 'quantity<_unit<&frame, &per, &second>::v, unsigned int>') to unary expression
  ~(pge_frames_per_second{});
  ^~~~~~~~~~~~~~~~~~~~~~~~~~
<source>:1483:3: error: invalid argument type 'Q' (aka 'quantity<_unit<&frame, &per, &pge_pixel, &second>::v, unsigned int>') to unary expression
  ~(pge_frames_per_second{} / pge_pixels<std::uint32_t>{});
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<source>:1484:3: error: invalid argument type 'Q' (aka 'quantity<_unit<&frame, &per, &pge_pixel, &gram, &second>::v, unsigned int>') to unary expression
  ~(pge_frames_per_second{} / pge_pixels<std::uint32_t>{} / quantity<gram, std::uint32_t>{});
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<source>:1485:3: error: invalid argument type 'Q' (aka 'quantity<_unit<&frame, &per, &pge_pixel, &gram, 60, &second, &squared>::v, unsigned int>') to unary expression
  ~(pge_frames_per_second{} / pge_pixels<std::uint32_t>{} / quantity<gram, std::uint32_t>{} /
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<source>:1487:3: error: invalid argument type 'Q' (aka 'quantity<_unit<&gram, &per, 60, &second>::v, unsigned int>') to unary expression
  ~(quantity<gram, std::uint32_t>{} / quantity<minute, std::uint32_t>{});
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[mpusz]

@JohelEGP, I must say it is really interesting. I am mostly concerned with the fact that you depend only on units, and you completely dropped dimensions. With that, the generic dimensional analysis is not possible, and also, some systems of quantities will be impossible to be modeled (i.e. natural units, a system where c = 1 so you can measure the distance in seconds). Having just units may also be challenging to do a proper analysis on not-related named units like Pascal and barye (unless you define one in terms of the other, but in such cases, the systems cannot work standalone).

As you quoted several times already, the BIPM says:

It is therefore important not to use the unit alone to specify the quantity.

[JohelEGP]

Indeed. It's currently a WIP proof of concept I'm building from the ground up.

Mp-units uses equivalent dimensions. For now, I plan to follow the example of the BIMP, and instead introduce the concept of quantity name. Like length and area. So energy, work, amount of heat, and moment of force all really have the same dimension. Pretty much like #32 (comment), I believe.

[mpusz]

For now, I plan to follow the example of the BIMP, and instead introduce the concept of quantity name. Like length and area. So energy, work, amount of heat, and moment of force all really have the same dimension. Pretty much like #32 (comment), I believe.

Yes, I work on something similar in #281. I just have some issues with the correct naming of entities there. I wanted to provide the initial branch under review before my vacation on Thursday, but it seems I will not be able to finish it until this time.

[JohelEGP]

Better names should become apparent with more eyes on it, and certainly more when its described by documentation. If that's all there's left to it, just share it.

[mpusz]

Naming is hard but also the implementation is far from being done. I will probably not be able to finish it in two days. But I am working on it and will continue doing it after my vacation, so hopefully, we will have some progress in this field soon.

[mpusz]

Done in V2.