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

[Marcin 'Qrczak' Kowalczyk]

Fri, 16 Mar 2001 15:18:43 +0200, Moshe Zadka <moshez at zadka.site.co.il> pisze:

> PEP: 237
> Title: Unifying Long Integers and Integers

I like it!

> Overflows
> 
>     When an arithmetic operation on two numbers whose internal
>     representation is as machine-level integers returns something
>     whose internal representation is a bignum, a warning which is
>     turned off by default will be issued.  This is only a debugging
>     aid, and has no guaranteed semantics.

I would not bother with this warning.

> 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.

The i is unified with length, not with digits[].

Isn't it simpler to have Int as Long as separate types? If they behave
in the same way, arithmetic on Ints yields longs when needed etc.,
it should be OK and nice. They can even return the same type(x)
and have a unified PyInt_Check, but operations are more naturally
dispatched as currently. It's probably unnecessary to normalize the
large form into the small form if the value gets smaller.

That way there are fewer places which have to dispatch on the
representation.

Wouldn't using gmp be an advantage?

> Open Issues

Let me add: I would like to have PyInt_AsString. I know I can convert
to a Python string object and get the C string from it, but it looks
like an unnecessary indirection.

I wanted PyLong_AsString to convert them for another bignum library.
There might be faster ways to do this, but every library will
understand decimal strings.

Unfortunately it's unclear how to obtain and free the storage, as
usual in C.

Well, maybe it's not that important.

>     What to do about sys.maxint?

Deprecate like the long function etc., unless some important libraries
would still be limited to that.

>     What to do about PyInt_AS_LONG failures?

A good question.

>     What do do about %u, %o, %x formatting operators?

If portability here is not that important, let them output negative
numbers as negative. One can use "%x" % (x % 2**32) to get the old
behavior.

If it is, I don't know.

>     How to warn about << not cutting integers?

If there is a portability switch like from __future__ import foo,
use that; it's bad that it doesn't happen at compile time, but maybe
it's all that we can get. If not, I don't know.

>     Should the overflow warning be on a portable maximum size?

I would drop it.

>     Will unification of types and classes help with a more
>     straightforward implementations?

I don't know.

> PEP: 238
> Title: Non-integer Division

I like it!

> Open Issues
> 
>     Should the // operator be renamed to "div"?

If % is % and not "mod", I would probably spell it //. But I would
call % "mod", except that it's too late.

> PEP: 239
> Title: Adding a Rational Type to Python

I like it!

I guess that sin(1.5) converts the argument to float?

How many digits does str(1/3) return, assuming it prints the number
in decimal?

Should str(5.0) return '5.0' or '5'? Note that it finally doesn't
hurt if you have an integer instead of a rational, so there is more
sense to let it return '5' than currently: integers can be treated
as a special case of rationals (implemented as a separate type).
But maybe accepting 4.0 as list indices etc. is too much.

What does repr(1/3) return? '1/3'?

> PEP: 240
> Title: Adding a Rational Literal to Python

I like it!

All PEPs together make arithmetic on literals exact, independent of
the platform's integer size and float representation. Moreover one can
always write 42 instead of 42.0 and get the same result (numerically).

BTW. A nice thing about static typing is that it allowed Haskell's
numeric literals and functions to have types deduced from the context
of usage. 5+1/3 can be computed on either Rational or Double or
Complex Float or any other (perhaps user defined) fractional type.
Literals are internally converted from Integer (infinite precision)
or Rational (= Ratio Integer). In Python it can't be done that way,
but the conversion can be delayed such that the results are the same
(modulo the *lack* of *loss* of precision if numbers are converted
to float too late).

-- 
 __("<  Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK