[Python-Dev] Revamping Python's Numeric Model
Sat, 04 Nov 2000 10:58:49 +0100
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: firstname.lastname@example.org (Moshe Zadka)
> Status: Draft
> Type: Standards Track
> Created: 4-Nov-2000
> 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.
> 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.
> are several things which can be considered "number methods":
> 1. isnatural()
> 2. isintegral()
> 3. isrational()
> 4. isreal()
> 5. iscomplex()
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 ?
Python Pages: http://www.lemburg.com/python/