Future division patch available (PEP 238)

[Marcin 'Qrczak' Kowalczyk]

Mon, 23 Jul 2001 05:34:57 +0100, Stephen Horne <steve at lurking.demon.co.uk> pisze:

> exp(1/2) is irrational - it cannot be represented as a float or as a
> rational - but the float representation can never be more precise than
> a rational representation, whereas a rational representation *can* be
> more precise than a float representation.

Rationals are used in cases when the result is exact, because it can
be exact when working with +-*/ and a few more. When I see a rational,
I expect that it's exact.

Floats are used in cases when the result is not exact, because it
can't be exact even for +.  When I see a float, I know that there is
an inaccuracy.

You can't give exact answer to exp(1/2) - Python won't have builtin
symbolic computation soon. It must be inexact anyway. Moreover, working
with rationals with huge nominators and denominators is ineffective;
there are not suited for approximating irrational numbers. If I really
wanted to work wirh inexact numbers with a better precision than
float, I'd use a custom float-like type with more precision. This
is unlikely - in reality the precision of float usually suffices
(in cases we allow the result to be approximate at all).

> If you argue that integers are just a subset of floats and division
> should always return a float if necessary to get the more precise
> value,

I would not call the difference between 3 and 3.6 "precision".
They are results of different operations, difference between these
numbers is huge.

OTOH the difference between 3.6 and the number closest to 3.6
representable as float is not big. This is precision.

>>Too late: it has already lost its precision because input was a float.
> 
> But why throw away the rational arguments precision.
> 
> 1/3 * 2.0 should give 2/3 - not 0.6666666666666

This is a rare case when the float was exact. In general floats are
not exact. If you *know* that it's exact, why it's a float in the
first place? Convert it to a rational or integer.

If one of arguments is inexact, the result is inexact.

This is how Lisp behaves BTW. Integer division yields a rational and
mixing floats with rationals yields a float. I didn't remember that
when I started argouing for it: it's just the most logical way of
how it should work.

> But if we use your logic for this case, then surely we should consider
> that in integer division there's no point giving a float result as the
> inputs are already represented as integers and therefore they have
> already lost the precision that floats have ;-)

Integers are exact!!! That's the point: if numbers represent inexact
quantities, they should be expressed as floats. Since working with
integers and rationals is predictable and +-*/div,mod give correct
(with int/int->rational), they should be used when we want to know the
true answer. If it's not possible anyway, use floats and don't waste
computation time for the 100th decimal place which is wrong anyway.

> But a rational approximation can more accurate than floats - surely
> we should choose the *best* approximation.

There is no best approximation: there is an infinite sequence of
better and better rational approximations.

> One major advantage of treating integer division separate from
> float division separate from rational division etc etc is simply
> that the rules stay the same for each case

Why should float division be separate from rational division?

> What the hell is a decimal float, and where did they come from! They
> only exist, to my knowledge, in the sense of standard form/scientific
> notation.

Guido was arguing for them :-)

> But you can't simply classify floats and rationals as alternatives
> like this - by your own logic, floats are a subset of rationals (just
> as integers are a subset of floats),

No. Integers represent mathematical integers (exactly). Rationals
represent mathematical rationals (exactlt). Floats represent
mathematical reals (inexactly).

-- 
 __("<  Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK