[Python-ideas] isinstance(Decimal(), Real) -> False?
Draic Kin
drekin at gmail.com
Thu Aug 29 10:13:35 CEST 2013
On Thu, Aug 29, 2013 at 4:02 AM, Steven D'Aprano <steve at pearwood.info>wrote:
> On 28/08/13 20:48, Draic Kin wrote:
>
>> For the same reason, I could think that isinstance(Decimal, Rational) ->
>> True
>>
>
> If Decimal were a subclass of Rational, so should float. The only
> fundamental difference between the two is that one uses base 10 floating
> point numbers and the other uses base 2.
>
> Another difference is, that precision of float is fixly limited. I
actually thought that Decimal is unlimited the same way as int, however
decimal.MAX_PREC is pretty big number. But you're right Decimal shouldn't
be subclass of Rational. However the original question was why it is not
subclass of Real.
>
> and issubclass(Rational, Real) -> False. It's more about exact vs.
>> non-exact computations which is orthogonal to number hierarchy.
>>
>
> The numeric tower is precisely about the numeric hierarchy of Number >
> Complex > Real > Rational > Integral, and since they are all *abstract*
> base classes, exact and inexact doesn't come into it. Concrete classes can
> be inexact or exact, or one could implement separate Exact and Inexact
> towers.
>
In practice, it's hard to think of a concrete way to implement exact real
> numbers. Maybe a symbolic maths application like Mathematica comes close?
>
>
>
> Maybe there
>> should be some ExactNumber abstract base class and some convention that
>> exact shouldn't coerce with non-exact. So Decimal + float should raise an
>> exception even if both would be subclasses of Real (and Decimal even of
>> Rational). Or maybe it would be enough if there were just non-exact
>> variants of Real and Complex since non-exactness if just issue of them.
>>
>
>
> Personally, I would implement inexact/exact as an attribute on the type:
>
> if type(x).exact: ...
>
>
> sort of thing.
>
> There were some points (possible against the idea of issubclass(Decimal,
Real) -> True) like Decimal doesn't coerce to float, you cannot convert
Fraction to Decimal easily, you cannot sum Fraction + Decimal. Maybe some
of the rationale for the behavior is the matter of exact vs. non-exact. So
for that reason the exactness rationale could be made explicit by adding
some indicator of exacness and base some coercion cases on this indicator.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130829/a95e20ad/attachment-0001.html>
More information about the Python-ideas
mailing list