Sergey B Kirpichev <skirpichev@gmail.com> added the comment: On Tue, Mar 23, 2021 at 10:21:50AM +0000, Mark Dickinson wrote:
Mark Dickinson <dickinsm@gmail.com> added the comment:
I assume, the reason is: there is no lossless conversion to float's (and vice verse). and in fact we _do_ have lossless conversion of floats to Decimal instances
Indeed, context precision doesn't affect this. (But still, reversed conversion is inexact in general).
- it's not obvious what the *type* of the result of some_float + some_other_decimal should be
Seems so, for a static typing. But Python is a dynamically typed language, isn't?
import gmpy2 gmpy2.mpfr('1.0') + 1.0 mpfr('2.0') 1.0 + gmpy2.mpfr('1.0') mpfr('2.0')
(ditto mpmath)
- it seems rather likely that any attempt to combine a float and a Decimal instance in this way is a bug, or at least something that hasn't been fully thought through by the developer, so we force the developer to make an explicit conversion
Maybe it's ok for base-2 multiprecision arithmetics, as in the example above. Maybe not. But in this case, if interoperability with float's (or any other implementation for numbers.Real) is a requirement for any numbers.Real-derived class - that should be documented. Perhaps, then there are bugs in mpmath/gmp2, which do claim they implement Real type: i.e. either they should't implement automatic conversion or don't claim they do implement numbers.Real.
For historical discussions, see #1682.
Thank you, I'll look into. ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue43602> _______________________________________