Safe integer division to different units

[nebkat]

When dividing integers we have to accept that truncation will occur, but sometimes our desired end-result unit would have provided better accuracy:

auto a = 10 * mp::si::metre;
auto b = 50 * mp::si::metre;
auto ratio_one      =  a / b;                  // 👍 0, understandable
auto ratio_percent  = (a / b).in(mp::percent); // ☹️ 0%
auto ratio_ppm      = (a / b).in(mp::ppm);     // ☹️ 0ppm

This is normally worked around be pre-multiplying by the target unit, and mp-units is no different:

auto a = 10 * mp::si::metre;
auto b = 50 * mp::si::metre;
auto ratio_one      =  a / b;                      // 👍 0 * mp::one, understandable
auto ratio_percent  = (a * 100 * mp::percent / b); // 😃 20%
auto ratio_ppm      = (a * 1000000 * mp::ppm / b); // 😃 200000ppm

Problem solved? Not quite - this only worked because a / b gave mp::one so we didn't have to factor it out.

What if we have something more complicated:

static constexpr auto mpg= mp::imperial::mile / mp::imperial::gallon;
static constexpr auto kmpl= mp::si::kilo<mp::si::metre> / mp::si::litre;

auto distance = 43 * mp::si::kilo<mp::si::metre>;
auto fuel = 3 * mp::si::litre;
auto consumption_kmpl = distance / fuel;                // 👍 14 km/l, understandable
auto consumption_mpg = (distance / fuel).force_in(mpg); // ☹️ 39 mpg, should be 40mpg

This time we can't just multiply the distance by $2.82481 \frac{mpg}{km/l}$ before dividing, as it's not an integer - but even if it was we've had to know in advance that our end result will be in km/l and calculate that constant ourselves, and that might not always be so obvious.

We could give up and turn everything to floating points, but the factorization we need to do to save ourselves is exactly the sort of calculation that the library is best at. It can easily figure out that the constant is actually:

$\frac{4,546,090mpg}{1,609,344km/l}$

---

Essentially what we would need is something similar to std::fma or Rust's muldiv - that would create the optimal factorization before performing the final division. I was initially thinking a member function q.divide_to<U>(d), but a standalone function would probably be a better fit.

mp::divide_to<mpg>(43 * mp::si::kilo<mp::si::metre>, 3 * mp::si::litre) == 40 * mpg;

[mpusz]

Thanks, @nebkat. That is a really interesting idea. @chiphogg, I wonder if Au has solved this issue already? We could consider adding such a function; however, there is one problem lurking here. What about the integer overflow problem? Should we always first scale lhs (if unit factor > 1) and then divide by rhs?

If we can only come up with a generic algorithm that will work for all possible combinations of lhs, rhs, and Unit, I would be happy to implement it.

[chiphogg]

Au doesn't have a solution for this yet, but I have thought about the problem before, and I think @nebkat nailed both the problem description and the ideal API for a solution. But of course, the details on the implementation will matter a lot.

For scale factors greater than one, my intuition is that pre-scaling the LHS would be the right call. You're right about the overflow problem being an issue. To me, this seems like just another argument that the library should have a robust approach to overflow. I know you're concerned about magic numbers, but in practice, having the safety surface is a huge enabler for safely using integer types.

The case where the scale factor is less than one is not one that I had previously considered. It would be interesting to cook up a few example use cases to play with the ideas.