[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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4