Derived scaled units confusion

[m5k8]

Hi,
Thank your for this great library. I'm using it successfully in data acquisition system. So far, I was using it for base units from SI system and things are straightforward.

Going further, I got to the point where I need to make some calculations with derived units.
I have area in square metres and volume in milliliters:

using namespace units::isq::si;
using area_in_m2 = area<square_metre, unsigned int>;
using volume_in_ml = units::isq::si::volume<millilitre, unsigned int>;

Now I'm trying to derive new scaled unit, and please excuse me, but some confusion arises - I need new unit: decilitre per square meter.
According to examples from manual, here comes derived unit:

struct decilitre_per_m2 : units::derived_unit<
  decilitre_per_m2, dim_volume_per_area, decilitre, square_metre> {};

But it needs it's own dimension (dim_volume_per_area here), and this I'm trying to declare as:

struct dim_volume_per_area : units::derived_dimension<
  dim_volume_per_area, decilitre_per_m2, units::exponent<dim_volume, 1>, units::exponent<dim_area, -1>> {};

This is cyclic dependency (unit requires dimension, dimension requires unit) that probably is my mistake, but I'm stuck for now and can't figure this out. Please advise...

Furthermore, I expect such example calculation to be correct (converting millilitres to decilitres in between):

using volume_per_area = units::quantity<dim_volume_per_area, decilitre_per_m2, unsigned int>;

volume_in_ml volume = some_volume;
area_in_m2 area  = some_area;
volume_per_area vpa = volume / area; // here: millilitres / m2 to decilitres / m2

Should I expect implicit casts to just happen, or do I need explicit cast to volume_per_area type?

[mpusz]

Hi, thanks for trying out the library.

It seems that we have an interesting use case here. It is even not about the cyclic problem you refer to above. The problem is bigger.

Volume divided by the area is just a length so you try to overwrite an existing base dimension. As a consequence decilitre per square meter is just a strange alias for a micrometre so a base unit of a length quantity. Unfortunately, as of now, I am not sure how to even implement this for a "derived unit" that is in fact a base one. We have some possibilities for derived quantities but this is a base one so it is not formed from a list of exponents of other quantities.

So let's try to cheat a bit here 😉:

using area_in_m2 = area<square_metre, unsigned int>;
using volume_in_ml = units::isq::si::volume<millilitre, unsigned int>;

using dim_volume_per_area = dim_length;
struct decilitre_per_m2 : units::alias_unit<micrometre, "dl/m2", units::no_prefix> {};
using volume_per_area = units::quantity<dim_volume_per_area, decilitre_per_m2, unsigned int>;

volume_in_ml volume(10);
area_in_m2 area(2);
volume_per_area vpa = volume / area;

https://godbolt.org/z/PoKzevfG1

I am not happy that I had to hardcode dl/m2 as a symbol of the unit but it should work for simple cases.

Please let me know how this solution addresses your concerns?

[m5k8]

Thanks for suggestions.

Volume / area is indeed length! :) In strictly technical point of view. In real world, I have some dosage of some chemistry in agriculture and real world unit is dl/m2, so I have to conform to reality.

There's problem with scaling in the suggested code:

struct decilitre_per_m2 : units::alias_unit<micrometre, "dl/m2", units::no_prefix> {};

decilitre_per_m2 is not micrometre. micrometre is 1 millilitre / 1 square metre and I need decilitres. On the end of the pipe I have some embedded device that does fixed point calculations, with dl/m2. Of course I can scale on output, but wanted to offload all this burden to the units library, that's what it's for. Isn't it?
So I need unit that's scaled by 0.0001. There's no SI prefix for this.
I came up with the following, temporary new unit - hectomicro = 100 * micro = 0.0001:

struct hectomicro : units::prefix<hectomicro, prefix, "hu", units::ratio(1, 1, -4) > {};
struct hectomicrometre : units::prefixed_unit<hectomicrometre, hectomicro, metre> {};
struct decilitre_per_m2 : units::alias_unit<hectomicrometre, "dl/m2", units::no_prefix> {};
using dim_volume_per_area = dim_length;
using volume_per_area_in_dl_per_m2 = units::quantity<dim_volume_per_area, decilitre_per_m2, unsigned int>;

Is there a better way to define this with alias_unit? Without my invented prefix?

All is good, more or less. It works as expected for this quantity, so thanks for the suggestion!
But now such simple code doesn't compile - error is "cannot convert from .. to ...":

volume_in_ml volume(10);
area_in_m2 area(2);
volume_per_area_in_dl_per_m2 vpa = volume / area;

I have to add explicit cast:

volume_per_area_in_dl_per_m2 vpa = units::quantity_cast<volume_per_area_in_dl_per_m2>(volume / area);

Is it expected behaviour?

I also have such calculation:

using some_coeff_in_percent = units::quantity<units::dim_one, units::percent, unsigned int>;
some_coeff_in_percent coeff{50};
volume_per_area_in_dl_per_m2 vpa{100};
vpa = vpa * coeff;

And last assignment also doesn't compile. It requires explicit cast:

vpa = units::quantity_cast<volume_per_area_in_dl_per_m2>(vpa * coeff);

Is it expected behaviour?

With all these casts, code becomes somewhat ugly...

[mpusz]

Please note that in most cases it is not recommended to bind calculation to a specific unit when an integral representation is being used. You should strive to achieve the best possible accuracy of the final result. This means that you should work on auto for most of the time and convert only the final result to a required unit (i.e. before printing on a screen or passing to some 3rd-party library).

using some_coeff_in_percent = units::quantity<units::dim_one, units::percent, unsigned int>;
some_coeff_in_percent coeff{50};
volume_per_area_in_dl_per_m2 vpa{99};

{
  volume_per_area_in_dl_per_m2 vpa1 = units::quantity_cast<decilitre_per_m2>(vpa * coeff);
  volume_per_area_in_dl_per_m2 vpa2 = units::quantity_cast<decilitre_per_m2>(vpa * coeff);
  volume_per_area_in_dl_per_m2 vpa3 = vpa1 + vpa2;
  std::cout << vpa3 << "\n";
}

{
  VolumePerArea auto vpa1 = vpa * coeff;
  VolumePerArea auto vpa2 = vpa * coeff;
  VolumePerArea auto vpa3 = vpa1 + vpa2;
  volume_per_area_in_dl_per_m2 vpa4 = units::quantity_cast<decilitre_per_m2>(vpa3);
  std::cout << vpa3 << ", " << vpa4 << "\n";
}

prints

98 dl/m2
9900 µm, 99 dl/m2

https://godbolt.org/z/rc4rvYfY6

[m5k8]

Thank you for your help! Great support. Really.
I know of all the problems with integer arithmetic, and I'm being careful with it. I just have embedded CPU without floating point and doing fp requires software fp routines, far from ideal - slow and code size issues.
One more question, why these declarations must use different convention?

struct millilitre_per_m2 : units::alias_unit<micrometre, "ml/m2", units::no_prefix> {};
struct decilitre_per_m2 : units::named_scaled_unit<decilitre_per_m2, "dl/m2", units::no_prefix, units::ratio(1, 1, -4), metre> {};

When trying to declare the following, compiler chokes:

struct millilitre_per_m2 : units::named_scaled_unit<millilitre_per_m2, "ml/m2", units::no_prefix, units::ratio(1, 1, -6), metre> {};

And, out of curiosity, how come that Compiler Explorer knows about units library, if it's not in standard compiler library yet?

[mpusz]

why these declarations must use different convention?

You cannot define the unit with the same ratio twice (the same applies to two dimensions having the same exponent list). In such a case the Donwcasting Facility cannot establish 1-to-1 correspondence between the "long" type generated by the framework and the one nicely named by the user. named_scaled_unit creates such a correspondence. When the library's framework will end und with metre^-4 it switches the type to decilitre_per_m2.

The problem with the millilitre_per_m2 is that there is already a micrometre unit predefined in the library. The best we can do in such a case is to define an aliased unit to micrometre. Please note, however, that the framework always will use micrometre as a primary unit (i.e. print it on the console) if not explicitly cast by the user to the aliased one.

[mpusz]

The above might change if we decide to get rid of the Donwcasting Facility from the library. However, from polls I did several times already users would prefer to keep it as it is now.

[mpusz]

how come that Compiler Explorer knows about units library, if it's not in standard compiler library yet?

See the "Libraries" button 😉

[m5k8]

Thanks for your thorough explanations! Now back to coding, I've chosen your library for my code and I hope to ask fewer and fewer questions (more knowledge on my side).

[mpusz]

In case you have any more questions please do not hesitate to ask.