Add support for `ratio<Num, Den, Exp>` about mp-units HOT 11 CLOSED

This is basically the way I did it in my Quan library, though I called the type "conversion_factor"
https://github.com/kwikius/quan-trunk/blob/master/quan/meta/conversion_factor.hpp#L52

I also found it useful to add an extra tag in the conversion_factor to distinguish conversion_factors that have the same value but represent different things: length::mil versus length::thou and non-si unit angstrom for example:
https://github.com/kwikius/quan-trunk/blob/master/quan/components/of_length.hpp#L126
https://github.com/kwikius/quan-trunk/blob/master/quan/components/of_length.hpp#L135
https://github.com/kwikius/quan-trunk/blob/master/quan/components/of_length.hpp#L224

from mp-units.

Already come across this limitation, definitely a TODO. I might try to have a look at this. Is it still a good issue to work on for starters?

from mp-units.

Yes, this is definitely something to do soon. Also as it is fairly isolated from the rest of the library framework I believe this a good place to start.

However, please note that the design mentioned in this thread may not be the best one (or not the only one). Please see a short discussion on prefixes in #37. Maybe just a prefix type needs a different ratio type that will be better suited to express prefixes and the ratio described here should be used only for scaled_unit but then we will need to provide interop between those 2 factor-like types.

If you want to start working on it please do it on a new_design branch as it is going to be merged to master really soon as I nearly finished with the rework of the library (basically only some cleanup and docs are missing).

In case you need any help please find me on Cpplang slack ;-)

from mp-units.

OK, understood thanks. Will have a look through. instinct is not to create a new type but try to stick to Exp=0 by default.

from mp-units.

Also, please note that at some point we will most probably move to NTTP ratio. I still have to check if it works fine with gcc-9.2 or only with gcc-10. All logic and arithmetics will remain the same though.

from mp-units.

OK, what kind of new NTTP signature, are you aiming for that requires c++20?

  template<std::intmax_t Num, std::intmax_t Den = 1>
      requires (Den != 0)
  struct ratio {
    static_assert(-INTMAX_MAX <= Num, "numerator too negative");
...

from mp-units.

See here: https://youtu.be/oNBnYhLxlTU?t=1473

from mp-units.

That's all really good but I wonder if that will merge well
Ie if i change the ratio templates and they get replaced by normal constexpr classes it may need to be hand merged no? Also will be 300% easier to debug and test in constexpr. Almost better to wait?

from mp-units.

You could alternatively use a big_ratio at that point and not worry about the exponent

https://github.com/kwikius/quan-trunk/blob/master/quan/big_rational.hpp

Meanwhile I am working on a nicer version of this type for c++11. ( C++2a is great but not likely to be easily available in embedded for a while) Will probably change name to conversion factor.

https://github.com/kwikius/pqs/blob/master/src/include/pqs/bits/ratio_exp_def.hpp.

from mp-units.

Its subjective. I actually prefer the exponent idea to huge numerators or denominator. Counting zeroes gets confusing at some point and its easier to think 10e9 etc

from mp-units.

@oschonrock I wasnt serious. Though whoever designed std::chrono didnt get the memo ! .
https://youtu.be/P32hvk8b13M?t=635
I have been using c++ quantities with compile time conversion_factors with base 10 exponents since around 2003 , quite a few years before std::ratio. Here is a thread with me discussing it back then , though most people didnt have a clue what I was talking about at the time and many still don't. ;-)
https://lists.boost.org/Archives/boost/2004/07/67476.php

from mp-units.