[Very Long (11K)] Numeric PEPs, first public posts
Rainer Deyke
root at rainerdeyke.com
Sat Mar 17 18:25:04 CET 2001
"Moshe Zadka" <moshez at zadka.site.co.il> wrote in message
news:mailman.984748941.31248.python-list at python.org...
> PEP: 237
> Title: Unifying Long Integers and Integers
> Rationale
>
> Having the machine word size exposed to the language hinders
> portability. For examples Python source files and .pyc's are not
> portable because of this. Many programs find a need to deal with
> larger numbers after the fact, and changing the algorithms later
> is not only bothersome, but hinders performance in the normal
> case.
A simpler way to solve this problem would be to standardize Python ints as
32 bit.
> Implementation
>
> The PyInt type's slot for a C long will be turned into a
>
> union {
> long i;
> struct {
> unsigned long length;
> digit digits[1];
> } bignum;
> };
>
> Only the n-1 lower bits of the long have any meaning; the top bit
> is always set. This distinguishes the union. All PyInt functions
> will check this bit before deciding which types of operations to
> use.
>From a performance point-of-view, it might be better to keep integers and
longs as separate types. Not sure if this makes any real difference.
> PEP: 238
> Title: Non-integer Division
> (a/b) * b = a (more or less)
>
> The type of a/b will be either a float or a rational, depending on
> other PEPs[2, 3].
Please, no floats. This newsgroup is evidence that floating point numbers
are much more confusing than integer truncation. Rationals I can live with,
but I think the operator '/' should keep its semantics and the new operator
should produce the rationals. This would be consistent with the current
system where 'a / b' has the same type as 'a' and 'b' if 'a' and 'b' have
the same type.
> PEP: 239
> Title: Adding a Rational Type to Python
> RationalType
>
> There will be a new numeric type added called RationalType. Its
> unary operators will do the obvious thing. Binary operators will
> coerce integers and long integers to rationals, and rationals to
> floats and complexes.
>
> The following attributes will be supported: .numerator and
> .denominator. The language definition will not define these other
> then that:
>
> r.denominator * r == r.numerator
>
> In particular, no guarantees are made regarding the GCD or the
> sign of the denominator, even though in the proposed
> implementation, the GCD is always 1 and the denominator is always
> positive.
I don't see the point in not guaranteeing this. Undefined behavior is bad.
> PEP: 240
> Title: Adding a Rational Literal to Python
> Abstract
>
> A different PEP[1] suggests adding a builtin rational type to
> Python. This PEP suggests changing the ddd.ddd float literal to a
> rational in Python, and modifying non-integer division to return
> it.
I very much like this idea (because I hate floats), but I suspect this will
break too much code. A suffix similar to the 'L' after long literals might
work better.
--
Rainer Deyke (root at rainerdeyke.com)
Shareware computer games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor
More information about the Python-list
mailing list