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

[Steve Holden]

"Marcin 'Qrczak' Kowalczyk" <qrczak at knm.org.pl> wrote in message
news:slrn9bconk.ns2.qrczak at qrnik.zagroda...
> 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!
>
[enthusiastic commentary omitted].
>
> >     What to do about sys.maxint?
>
Why not return floating-point infinity? <0.25 wink>

> 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.
>
So, longs become variable-length two's-complement integers?

> 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.
>
How about:

    from __future__ import unified_field_theory

?

> >     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.
>
No it isn't. It's never too late to _suggest_ a change :-) I seem to
remember suggesting that "print >>" could be omitted without making me cry.


> > PEP: 239
> > Title: Adding a Rational Type to Python
>
> I like it!
>
> I guess that sin(1.5) converts the argument to float?
>
Well, it shouldn't need to, unless the default numeric literal is a
rational: 1.5 already _is_ floating point, isn't it?

> How many digits does str(1/3) return, assuming it prints the number
> in decimal?
>
Forty-two. This might even have been the original question to which this is
the answer.

> 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.
>
This seems to conflict with dictionary semantics, where for all integer i,

    dict.has_key(i) == dict.has_key(float(i))

> What does repr(1/3) return? '1/3'?
>
Unless you think '20/60' or '12.7/38.1' might be better: it would seem that
the canonical representation of rationals would use remove a factor of
GCD(numerator, denominator). But, then, this is not my specialty.

> > 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).
>
I really don't want my languages deciding what representations to use for my
data: otherwise, what happens to guarantees that they can be persistent in
bounded storage?

> 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).
>
Surely rationals with infinite-length components will always be more
precises than your average floating-point number for strictly rational
values?

or-should-we-go-the-whole-hog-and-use-a-long-for-the-floating-
    point-characteristic-as-well-ly y'rs  - steve