[Python-Dev] Revamping Python's Numeric Model

[Moshe Zadka]

[GvR]
> So I go offline for a couple of days to entertain guests and have my
> body kicked around in a dance class, and I have 25 messages discussing
> Python's numeric model waiting for me...

I think the solution is obvious -- stop going offline to entertain guests.

[GvR]
> I was hoping that Tim would chime in

Me too. I even tried to drag him in by mentioning 754.

[GvR]
> I like the idea of a PEP to rework the numeric model.  I think that
> Moshe, being a mathematician by training, will make a good editor.  I
> think that this has a snowball's chance in hell to make it into Python
> 2.1 however -- there are many deep issues, and it's a bad idea to
> experiment too much in the released version of the language.

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.


[GvR]
> (1) As long as the internal representation is not the same as what is
>     commonly printed, there will be surprises -- with rationals just
>     as much as with floating point.  There are issues with decimal
>     floating point too, but they are only the issues having to do with
>     loss of precision in the calculation (e.g. 1.0 - 1e-20 yielding
>     1.0) and not with loss of precision in the printing, where most of
>     the "bug reports" we get seem to concentrate.

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

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

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

[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?

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

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

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.
-- 
Moshe Zadka <sig@zadka.site.co.il>