[Python-Dev] Revamping Python's Numeric Model

[Guido van Rossum]

[Moshe]
> The reason the PEP was written now was because you started making sounds
> of causing 1/2 to be 0.5, which is dangerous. I tried to outline the PEP
> to show a less dangerous (and less innovative) way of getting similar
> usability.

1/2 yielding 0.5 is innovative?  Give me a break.  Pascal did this.
Algol-60 did this.  Fortran does this.  And rational numbers are less
innovative?

And what's dangerous about 1/2 yielding 0.5?

> My PEP does not yet deal with either written or inputted representation.

These affect the numeric model though (see Tim's posts) so should be
considered.

> [GvR]
> > (2) Rational numbers have the unpleasant property of growing
> >     unboundedly during many innocent calculations, thereby using up
> >     exorbitant amounts of memory and slowing down the calculation --
> >     often mysteriously, because what is displayed is truncated.
> 
> Those calculations, if performed with floating points, would often build
> up inaccuracy. I prefer to go slow+memory hog (which the user feels), then
> to be wildly inaccurate.

That's your choice.  Wildly inaccurate is sometimes unavoidable.  This
is clearly an issue open for debate, but note that I speak from
experience: ABC used rationals unless you forced it to use reals, and
the rationals *did* cause real users to complain about how slow ABC
was.

> [GvR]
> > Another issue that I might bring up is that there are no inexact
> > numbers (each floating point number is perfectly exact and rational)
> 
> You'll note that my PEP does not mention floating point explicitly --
> and once again I mention that my PEP does not yet deal with number
> literals. All it allows (not requires) is for things like math.sqrt()
> to return inexact results. Naive implementations (which we might use)
> would make math.sqrt(1) an *inexact* 1, tentatively called 1.0. Of 
> course, good implementations of math.sqrt() would realize that 1 has
> an exact root, but that might be too hard to do for not enough gain.

Without a clear implementation plan your PEP is incomplete, PEP
guidelines notwithstanding.  Quality of implementation is important
for such a basic feature!

> [GvR]
> > If we take its meaning literally, the isreal() function should only
> > return true for numbers for which isrational() is also true:
> 
> Correct -- in my current model. If you later add things like constructive
> reals, that is no longer true: if I have a constructive Pi, it's not 
> rational. 
> 
> [GvR]
> > mathematically speaking, real numbers that aren't also rational don't
> > have an easy finite representation, since they are numbers like
> > sqrt(2) or pi.
> 
> But numbers don't have to have a finite (periodic really) representation
> to be representable in the computer: what about infinite continued fractions,
> for example?

So the question is, what implementation do you have in mind?  You
can't just go prescribe idealistic semantics and hope it gets
implemented by magic (even Tim can't do that :-).

> [GvR]
> > Finally, the PEP doesn't talk about how the numeric model can be
> > extended
> 
> That's because its rich enough not to need it. 
> Let me explain exactly what I mean: as long as all field operations between
> Python numbers give honest to god Python numbers, then everything else
> can be solved with Python's current model of coercions, and can be solved
> well when the coercion PEP will be written.

I think this deserves very explicit mention in your PEP.  An example
of how I would go about implementing my own Rational class or
extension type would help.

Also, the coercions PEP is still in need of an author.  Maybe you want
to take this on too?  It will help your numeric proposal if you can
write down how you think coercions should work.

> [GvR]
> > I've
> > heard of wild floating point representations that make multiplication
> > and division really cheap but addition a pain, rather than the other
> > way around;
> 
> Well, no problems: write wild.inexact()  and wildmath.{sqrt,...} and use
> that instead of inexact() and math.{...}. How these numbers interact
> with builtin Python numbers is your responsibility -- and that's what
> the coercions are for.

So explain how to do the coercions.  This will force you to be
explicit about implementation details.  (Both from Python and from C.)

> Same goes for gmp: as long as you're not expecting to be able to change
> 10000000000+10000000000 to be a gmp long rather then a Python long, then
> there shouldn't be a problem.

Fair enough.

--Guido van Rossum (home page: http://www.python.org/~guido/)