Sergey B Kirpichev <skirpic...@gmail.com> added the comment:
On Tue, Mar 23, 2021 at 10:21:50AM +0000, Mark Dickinson wrote:
> Mark Dickinson <dicki...@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 <rep...@bugs.python.org>
<https://bugs.python.org/issue43602>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
