Been there, done that – fallen into the big pit awaiting the unwary mixing double and multiprecision – again and again… L

I am being bit by this one hard. Converted a bunch of multipliers and tolerances from mpfr_floats to doubles in an effort to simplify some code, and now mixed precision is introducing error.

I think that you don’t really want to delete a family of operator*s – what you DO want to get a warning when there is loss of significance, similar to the warning when you fit a double into a float.

It’s OK to multiply (or other ops) with a double as long as this doesn’t lose any bits or digits of precision.

So multiplying by 0.5 is OK, but not by multiplying 0.1 (the multiprecision type needs FP_type(1)/10 to represent 0.1 as accurately as possible for the FP type).

Multiplying by 0.1 is a common desire in my household (adaptive precision solving of polynomials). If only the compiler provided a trait bool is_exactly_representable(double)

so that a warning could be issued…

This is a bit tricky, because any double is by definition exactly representable by a double, right?. You would want is_exactly_representable to get the value before being transformed into a double? Another issue I foresee having to deal with is runtime parsing. Forbid the runtime user from feeding doubles problematic numbers. Thanks for the help, Dani