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.