About Rational Number (PEP 239/PEP 240)

[Lie]

> Rationals are not that simple.

So do complex number, in fact most people are much more familiar with
rationals/fractions than with complex number. And notice that I don't
use the word simple, I use the word elementary. Elementary doesn't
always means simple (although it usually is), but rather it emphasizes
on it being essential and being a basic building block for other
things.

And if you think about it, floating numbers aren't that simple either.
It only seems simple because it's implemented natively in the
hardware, but I'm sure the engineers creating them have a heated
discussion when they first try to implement it. Remember the
discussion about Decimals? How many rounding methods are there?

> * Unless you are working under very controlled conditions, rationals
> very quickly grow enormous numerators and denominators, hence
> require arbitrary precision integers (which, I concede, are part of
> Python).

One part of the problem is solved (arbitrary length integers) another
problem is the growth of rationals. That could have easy workaround,
like a scientific calculator, by using a special operator to construct
a fractions, people would only _consciously_ use fractions, avoiding
unexpected return of fraction AND controlled environment for using
fraction. It's also possible to have lossy_simplify(n[, acc]) method
for calculations that need rationals but don't need such accuracy (in
that case, perhaps float could be a better substitute).

> * In order to have a canonical representation of integers, they need
> to be kept in normalised form.

There are methods to simplify fractions and there are addition,
subtraction, division, multiplication, etc can be made to
automatically returns the most simple form.
[btw, off topic, in music, isn't 1/4 and 2/8 different? I'm not very
keen of music though, so correct me if I'm wrong.]

> * Having yet another numerical type would make it difficult what
> type to expect from a calculation.
There is a simple rule of thumb:
If a (built-in) method receives floats returns floats, else returns
fractions << Please don't take me too literally here, apply some
compromises.
The rationale is simple: Float's can't be turned easily into fraction,
while the otherwise involves only a simple true division.

> Which only seems to me to prove that having integer division return
> a floating value is a mistake
Oh no, it's not a mistake. Only IEEE's floating point standard isn't
sufficient to cope with exact arithmetic. Another reason to use
fractions.

> So while rationals might be useful to have available for
> some things, you should have to explicitly ask for them.
> Returning rationals from '/' applied to integers would
> be a bad idea, for example.

> From my reading of the PEP, it doesn't suggest such automatic
> coercions (neither rejects them explicitly though). Given the huge
> discussions about integer vs true division, it would be very
> controversial to suggest implicit rational division.

Which I agree, implicit rational division would be evil. People should
explicitly use fractions, using a special division operators, just
like calculators (although mine seems to always use fractions 'behind-
the-scenes' whenever possible, but on presenting them to the user it
does the rule of thumbs I mentioned).

> Regardless, a builtin (or at least standard library) rational type
> would be nice to have. Of course folks that *really need* rationals
> are already using some 3rd party library, but for the rest of us it
> would be an improvement in several cases where currently floats are
> used, just like the motivation for Decimals. Only difference seems to
> be that there aren't so many or compelling use cases for rationals as
> for decimals (mainly money counting).

People have, for ages used floating numbers in calculation on
occasions where it shouldn't be used, and that's a really bad practice
and even prominent (paper) mathematician are accustomed to such
practice. Floating numbers involves rounding and continued use of them
would make the value wanders off far away.