On Tue, Mar 23, 2021 at 01:03:47PM +0000, Mark Dickinson wrote:
> What do you think the result of `1.0 + Decimal(1)` should be, and
> more importantly why? Possible options are:
> 
> - Decimal('2')
> - 2.0 (a float)
> - a `TypeError` (as now)
> - some kind of horrible user-configurable-global-state-dependent answer

Decimal, with a some kind of "horrible
user-configurable-global-state-dependent answer" (Decimal
context): reverse conversion might be inexact.
Same, in principle, holds for 2-base multiprecision arithmetic
types like gmpy2.mpfr and mpmath.mpf.  "More powerfull data type,
claiming it implements numbers.Real - should know better."
That's the first option.

Maybe I (and authors of mentioned above packages) - do miss something
important.  (Oh, count on SageMath too.)
But do we have other examples of numbers.Real implementations (or
claiming to be such)?  If the numbers.Real does mean something like "only
python's builtin floats, but maybe with a different multiplication
algorithm" - that's hardly something that people may expect from
the docs.  Real numbers have a very specific mathematical meaning and
things like mpmath's mpf or Decimal fit this.

> Bear in mind that you have to pick a behaviour that's a good default
> choice for all potential application domains, and that's *hard*.

I think, that TypeError (a second option) might make sense too.  I'm not
sure that different implementations of numbers.Real must be interoperable (i.e.
without explicit conversions).  Such requirement clearly does make sense for
exact data types in the numerical tower (i.e. different
numbers.Rational implementations).

So, this implementation of the numbers tower:
  int (Integral) - Fraction (Rational) - float (Real) - complex (Complex)
doesn't look "more correct", than this:
  gmpy2.mpz - gmpy2.mpq - gmpy2.mpfr - gmpy2.mpc
regardless on how do "inexact" data types (e.g. float vs mpfr)
interoperate.  Same may be for the Decimal (but this is not a full tower):
  int - Fraction - Decimal.