Future division patch available (PEP 238)

[Stephen Horne]

On 22 Jul 2001 18:06:27 GMT, Marcin 'Qrczak' Kowalczyk
<qrczak at knm.org.pl> wrote:

>It's not that simple, e.g. exp(1/2) should return a float. Generally

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.

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, then surely you should also argue that floats are merely a
subset of rationals and rationals should be used where necessary to
get more precision.

Of course I don't agree - but I am simply extending your logic.

>> Logically, operations with mixed float and rational arguments should
>> give rational results - the float argument can be accurately
>> converted, and the result is less likely to have lost 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

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 ;-)

>But floats are used to represent their approximations. We have two
>choices about the meaning of pi+1/2: either 3.641592653589793 or
>3+180592277226915/281474976710656. I think that the former is a better
>choice; it's inexact anyway, so we should not pretend that it's exact.

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

>> Of course, this then opens a major can of worms - rational versions
>> of trig functions and similar would not be realistic, and therefore
>> you'd get lots of implicit conversions from floats to rationals
>> (rationals being more general than floats) only to have to convert
>> back again for the trig functions, and so on.
>
>That's why I would do it in the opposite direction.

So would I in reality - I'm simply extending the same logic you use
for integers and floats. 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 - your
not making up new inconsistent rules for each special case that
someone thinks up.

>
>>>  Decimal floats should not be necessary: they are inexact
>>>  like binary floats and slow like rationals.
>> 
>> Floats are not slow on modern hardware.
>
>This is what I said.

Sorry - I just realised what you are saying - *decimal* floats.

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.

>When you want speed, use floats. When you want correctness, use
>rationals. You can't have both. Decimal floats provide neither.

Decimal floats provide the same as binary floats but different - they
can be precise in cases when binary floats cannot and visa versa. But
I agree there's no real advantage, unless you were to argue that they
are more suited to the kinds of approximations that people naturally
make - we typically round to decimal places, not binary places.

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), so 1.0 divided by 3.0 should give
the rational 1/3.

Its your argument - why aren't you sticking to it ;-)