PEP239 (Rational Numbers) Reference Implementation and new issues

[Chris Gonnerman]

----- Original Message ----- 
From: "Christian Tismer" <tismer at tismer.com>


> Chris Gonnerman wrote:
> [snipped all the other good stuff]

[snipped all the other good stuff again]
> > Yeah, I'm the one who has been arguing in favor of a
> > decimal arithmetic type in the standard library.  Ask 
> > me to support rationals in the standard library, and I'll
> > back you up.  Heck, I'll even accept (optional) rational
> > literals, like the way we do longs.  (As long as you 
> > support (optional) decimal literals in return... :-)
> 
> Ok, we have a deal.

Excellent!

[ hack hack hack ]

> Naa, this is slightly different.
> I don't think al too many people asked for an integer
> in the first place when they wrote
> 
>    1/3

Ahhh...

you are thinking, "1/3 as a literal" and I am seeing it as
an EXPRESSION.  So to you, this:

    1/3

is not the same as this:

    n = 1
    m = 3

    n/m

Or have I misunderstood?  Because if you give me a rational
for the second option I'll be royally ticked off.  For the
first option, giving me a rational serves me right.
 
> Now suddenly for some reason out of this thread's scope
> Python reconsiders and thinks it should change this.
> So the target of this whole thing is (AFAIK) to figure
> out which type to return as the result of integer division?

I was against changing the integer division rules (I still
am) but I only have one module affected negatively by it,
so I stopped whining.

(Except when someone brings it up...)
 
> So you would suggest to stick with 1/3 == 0, or return
> a float, or a rational?

1/3 as an expression; whether I get 0 or 0.333... depends
on the Python version.  I just don't want a THIRD option 
(gah).

> The latter makes no sense, since this would save the R.

(I don't understand that statement)

> Personally, I don't like the idea to change 1/3 at all
> not very much. I see Python doing too much adjustments
> at the moment.

My reason for not liking automatic insertion of rationals.

> Making 1/3 return a float felt like a bad idea, after it
> had been int for so many years. Enforcing the float
> has become a habit where it's needed.

I agree on both counts.

> Now, returning a true fraction instead sounds exciting.
> Having fractions in the language is exciting as well,
> after I had them in Mathematica for long years.

... let's not get too excited here ...

> Finally, if I had to choose, I would either stick with
> the old truncation, or use rationals.
> Rationals would be welcome, even if there were just
> an extension module.

Now that idea I can get behind.  I'd never use them, but
(IMHO) you can never have too many tools in the box.

What I was proposing wasn't actually

    1/3R

as a rational literal; THIS is a rational literal:

    3R

and since math operations involving a rational and an int
or float would "promote" the int or float to rational, this:

    1/3R

would return a rational one-third value.

In other words, the R suffix would make a literal integer
"n" into a rational of the form "n/1".

Chris Gonnerman -- chris.gonnerman at newcenturycomputers.net
http://newcenturycomputers.net