Moshe Zadka wrote: > > Here's a draft PEP. > Have I already mentioned how much it irks me to cater for other > editors in the PEP text itself? > > PEP: Unassigned > Title: Reworking Python's Numeric Model > Version: $Revision$ > Author: pep@zadka.site.co.il (Moshe Zadka) > Status: Draft > Type: Standards Track > Created: 4-Nov-2000 > Post-History: > > Abstract > > Today, Python's numerical model is similar to the C numeric model: > there are several unrelated numerical types, and when operations > between numerical types are requested, coercions happen. While the C > rational for the numerical model is that it is very similar to what > happens on the hardware level, that rational does not apply to Python. > So, while it is acceptable to C programmers that 2/3 == 0, it is very > surprising to Python programmers. > > Rationale > > In usability studies, one of Python hardest to learn features was > the fact integer division returns the floor of the division. This > makes it hard to program correctly, requiring casts to float() in > various parts through the code. Python numerical model stems from > C, while an easier numerical model would stem from the mathematical > understanding of numbers. > > Other Numerical Models > > Perl's numerical model is that there is one type of numbers -- floating > point numbers. While it is consistent and superficially non-suprising, > it tends to have subtle gotchas. One of these is that printing numbers > is very tricky, and requires correct rounding. In Perl, there is also > a mode where all numbers are integers. This mode also has its share of > problems, which arise from the fact that there is not even an approximate > way of dividing numbers and getting meaningful answers. > > Suggested Interface For Python Numerical Model > > While coercion rules will remain for add-on types and classes, the built > in type system will have exactly one Python type -- a number. While I like the idea of having the numeric model in Python based on a solid class hierarchy, I don't think that this model is implementable in Python 2.x without giving away performance. > There > are several things which can be considered "number methods": > > 1. isnatural() > 2. isintegral() > 3. isrational() > 4. isreal() > 5. iscomplex() +1. I would like to see methods on Python numbers too (after having made some really good experiences with methods on strings ;-). There's one problem though: how would you call these on numeric literals ? ... 1.2.isreal() ?! > a. isexact() > > Obviously, a number which answers m as true, also answers m+k as true. > If "isexact()" is not true, then any answer might be wrong. (But not > horribly wrong: it's close the truth). Not sure what you mean here: perhaps .isexact() <=> can be represented in IEEE ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
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