PEP239 (Rational Numbers) Reference Implementation and new issues
chris.gonnerman at newcenturycomputers.net
Thu Oct 10 03:00:13 CEST 2002
----- 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.
[ 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
you are thinking, "1/3 as a literal" and I am seeing it as
an EXPRESSION. So to you, this:
is not the same as this:
n = 1
m = 3
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
> 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
as a rational literal; THIS is a rational literal:
and since math operations involving a rational and an int
or float would "promote" the int or float to rational, this:
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
More information about the Python-list