[Very Long (11K)] Numeric PEPs, first public posts

[Rainer Deyke]

"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