[Python-Dev] Revamping Python's Numeric Model
Tue, 07 Nov 2000 03:30:05 +0200
> 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
> 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
OK, I take back the innovation claim.
> 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.
> 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
I agree. That's why they are in the "unresolved issues" of the PEP.
> (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
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.
> 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!
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.
> 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.
> 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.
> 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.
> 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 <firstname.lastname@example.org>