[Python-Dev] Revamping Python's Numeric Model

[M.-A. Lemburg]

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/