[Edu-sig] RE: Rationals

[Guido van Rossum]

> Was the "int/int --> float" decision made before the "rational" numeric
> type was being considered?

PEP 238 actually says that it should be a rational when we have
rationals.  But I am now getting second thoughts about whether it is
really a good idea to make rationals this pervasive.

> A few years/releases down the road, if int's
> and float's and rational's are all in common usage, the decision to make
> int/int yield a float may be as perplexing (to some people) as "3/2
> yields the integer 1" is perplexing now (to some people).

Hardly.  Float and rational both give a useful answer to questions
like "how much is 1/3".  When you print the result, you'll usually
want it in decimal notation, so the fact that the rational is "more
exact" doesn't do you any good.  This is fundamentally different from
the answer you get for 1/3 today.

I'm not saying that float is necessarily the better answer -- just
saying that it's not as a perplexing as 0.

Th arguments for choosing float stem from conservatism: we don't know
how well returning a rational works in practice.  This would be a good
exercise to try though.

> I like this point of Kirby's:
> 
>    >> Sometimes people *want* floats from ints, so the compromise
>    >> of making at least one int a rat, in order to get a rat,
>    >> seems worth making (to me).
> 
> Could Python officially support multiple "numeric modes"?

I think this is a bad idea, at least when there is a single "global"
mode: different parts of the library may require different modes, and
temporarily switching the global mode to suit your own needs is
fraught with errors (even if you restrict it to your own thread).

This idea and similar ideas (e.g. a "fuzz" for comparisons) *always*
comes up when the various choices in numerics are discussed, and they
are always shot down for these reasons.

--Guido van Rossum (home page: http://www.python.org/~guido/)