[Python-Dev] Revamping Python's Numeric Model

[Moshe Zadka]

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

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

OK, I take back the innovation claim.

[Guido]
> And what's dangerous about 1/2 yielding 0.5?

Nothing, but then people would expect 1/3 to yield 0.333333333....,
while simultaneusly expecting (1/3)*3 == 1.
IOW, shoving floating points in people's faces is not user-friendly.

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

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

I agree. That's why they are in the "unresolved issues" of the PEP.

[Guido]
> (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.

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

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

Well, experiences differ. I'm on the Scheme48 (which uses rationals) mailing
list, and nobody ever complained. Besides, if "forcing" is simply saying
either inexact() (and note that inexact-exact operations are performed
inexactly) or mixing in an inexact literal (assuming that's what 1.0 will
be), it might be easier. I don't know ABC well enough to say how the
forcing mechanism worked.

[Guido]
> Another issue that I might bring up is that there are no inexact
> numbers (each floating point number is perfectly exact and rational)

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

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

Well, I agree. When I set down to complete the PEP, I'll go over all
the math/cmath functions and remark how the implementation should change.
I also plan to draft an implementation design. I just wanted to throw
the idea out into the open, to get some feedback -- in no way can the
PEP be considered complete.

[Guido]
> 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 :-).

Well, for constructive reals, none. It's too much of pain to implement,
and too little to gain. That wouldn't preclude a later day implementation,
in case it turns out not to be the case. Besides, the tower wouldn't
look clean without it.

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

Well, I don't see why there should be a difference from what happens
currently. The thing is, the model will not support you telling it
at runtime what the results for operations on types it already knows
should be: that would make us Scheme, not Python. 

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

Smooth, real smooth. OK, sold to the highest bidder -- I take it.
I'll update it and 0000, and start reading MAL's pages.

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

Again this is no different from current day Python, modulu other PEPs. <wink> 
-- 
Moshe Zadka <sig@zadka.site.co.il>