About Rational Number (PEP 239/PEP 240)

[mensanator at aol.com]

On Dec 15, 2:00 pm, Lie <Lie.1... at gmail.com> wrote:
> I'm very surprised actually, to see that Python rejected the use of
> fractional/rational numbers. However, when I read the PEP, I know
> exactly why the proposal was rejected: People compared fractions with
> integers, while it should be more fairly compared to floats.

Pretty lame reasoning, isn't it?

I use the rationals from the gmpy module very
successfully.

All these arguments that follow are just silly.

>
> Arguments against:
> - When I use the result of / as a sequence index, it's usually an
> error which should not be hidden by making the program working for
> some data, since it will break for other data.
> ----> In Python 3 (and 2 w/ __future__), the / operator would always
> return floats, and floats is invalid as sequence index, even if the
> value of the float is whole. Since fractions is created with the /
> operator on two integers, the behavior of fractions should mimics
> float. So putting fractional type as sequence index should always be
> considered as error (exception), a behavior consistent with floats.
> Thus, the arguments specified above has turned invalid, at least in
> Python 3.
> - (this assumes the same type for them:) Int is a good type in itself,
> not to be mixed with rationals.  The fact that something is an integer
> should be expressible as a statement about its type. Many operations
> require ints and don't accept rationals. It's natural to think about
> them as about different types.
> ----> I agree, ints shouldn't be mixed with rationals. But floats
> could. This argument is the main reason why I said most people
> compared rational with integers. Many operations that requires ints
> and don't accept rationals also don't accept floats.
>
> Other arguments:
> - Slow: Doing addition and subtraction in fractions sure is expensive,
> but doing division (the heaviest arithmetic operation) is extremely
> fast in fractional numbers compared to in floating numbers. It is
> clear that doing two integer multiplication and switching numerator-
> denominator is much faster than doing a single float division.
> - Memory Intensive: To represent 1/3 to infinite accuracy requires two-
> integer-space (theoretically, 2 bytes). There are some numbers that
> are hard to represent in fractions, yes, but in general those numbers
> could be represented using two-long-space (variable-width longs). And
> whenever accuracy isn't that important, it could be possible to create
> a method that would lossily approximate the current fraction to an
> acceptable length. Anyway, most computers nowadays is packed with
> gigantic memory, why bother with such a small issue.
> - Rationals must present themselves as decimal floats or it'll be
> confusing: There will be no confusion in a good written code.
> Progammers that writes good code would always use the 'behind-the-
> scene' number, they wouldn't convert a previously 'string'ed number
> back into calculation. And a convention can be created to represent a
> fraction in a single line output (like * for multiplication, / for
> division, they don't exist in paper maths) that would completely
> eliminate any confusion of the user (well informed about the
> convention, most people that never used computer before often tried to
> use x and : to represent mult and div), even when the fractional
> number is outputted to the foreground UI.