Path: csiph.com!usenet.pasdenom.info!aioe.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <CAPTjJmqzhDb3FBuua7oy4osH7A0ODb7=T58WAvXQs5WhEdsOKQ@mail.gmail.com>
References: <51f68d9c$0$30000$c3e8da3$5496439d@news.astraweb.com> <-tidnZTes6qk72TMnZ2dnUVZ8kadnZ2d@giganews.com> <51f9fe27$0$30000$c3e8da3$5496439d@news.astraweb.com> <CAPTjJmqzhDb3FBuua7oy4osH7A0ODb7=T58WAvXQs5WhEdsOKQ@mail.gmail.com>
From: Oscar Benjamin <oscar.j.benjamin@gmail.com>
Date: Thu, 1 Aug 2013 10:44:12 +0100
Subject: Re: Unexpected results comparing float to Fraction
To: Chris Angelico <rosuav@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: python-list@python.org
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.72.1375350274.1251.python-list@python.org>
Lines: 58
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:51724

On 1 August 2013 07:32, Chris Angelico <rosuav@gmail.com> wrote:
> On Thu, Aug 1, 2013 at 7:20 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> I know this, and that's not what surprised me. What surprised me was that
>> Fraction converts the float to a fraction, then compares. It surprises me
>> because in other operations, Fractions down-cast to float.
>>
>> Adding a float to a Fraction converts the Fraction to the nearest float,
>> then adds:
>>
>> py> 1/3 + Fraction(1, 3)
>> 0.6666666666666666
>
> Hmm. This is the one that surprises me. That would be like the
> addition of a float and an int resulting in an int (at least in C; in
> Python, where floats have limited range and ints have arbitrary
> precision, the matter's not quite so clear-cut). Perhaps this needs to
> be changed?

The Python numeric tower is here:
http://docs.python.org/3/library/numbers.html#module-numbers

Essentially it says that
    Integral < Rational < Real < Complex
and that numeric coercions in mixed type arithmetic should go from
left to right which makes sense mathematically in terms of the
subset/superset relationships between the numeric fields.

When you recast this in terms of Python's builtin/stdlib types it becomes
    int < Fraction < {float, Decimal} < complex
and taking account of boundedness and imprecision we find that the
only subset/superset relationships that are actually valid are
    int < Fraction
and
    float < complex
In fact Fraction is a superset of both float and Decimal (ignoring
inf/nan/-0 etc.). int is not a subset of float, Decimal or complex.
float is a superset of none of the types. Decimal is a superset of
float but the tower places them on the same level.

The real dividing line between {int, Fraction} and {float, Decimal,
complex} is about (in)exactness. The numeric tower ensures the
property that inexactness is contagious which I think is a good thing.
This is not explicitly documented anywhere. PEP 3141 makes a dangling
reference to an Exact ABC as a superclass of Rational but this is
unimplemented anywhere AFAICT:
http://www.python.org/dev/peps/pep-3141/

The reason contagious inexactness is a good thing is the same as
having contagious quite NaNs. It makes it possible to rule out inexact
computations playing a role in the final computed result. In my
previous post I asked what the use case is for mixing floats and
Rationals in computation. I have always considered this to be
something that I wanted to avoid and I'm glad that contagious
inexactness helps me to avoid mixing floats into exact computations.


Oscar