[Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

[Travis E. Oliphant]

Forgive my ignorance, but I'm not really sure what this PEP is trying to 
do.  I don't want to sound negative, I really just don't understand the 
purpose.  I've just never encountered a problem this that I can see how 
this PEP will help me solve.

That doesn't mean it's not worthwhile, I just don't understand it.

> 
> Abstract
> ========
> 
> This proposal defines a hierarchy of Abstract Base Classes (ABCs)
> [#pep3119] to represent numbers and other algebraic entities similar
> to numbers.  It proposes:
> 
> * A hierarchy of algebraic concepts, including monoids, groups, rings,
>   and fields with successively more operators and constraints on their
>   operators. This will be added as a new library module named
>   "algebra".
> 

The SAGE people may be interested in this, but I doubt there will more 
than a handful of users of these algebraic base classes.


> * A hierarchy of specifically numeric types, which can be converted to
>   and from the native Python types. This will be added as a new
>   library module named "numbers".
> 

I could see having a hierarchy of "numbers"  we have one in NumPy.  All 
the NumPy array scalars fall under a hierarchy of types so that it is 
easy to check whether or not you have signed or unsigned integers, or 
inexact numbers.


> 
> Object oriented systems have a general problem in constraining
> functions that take two arguments. To take addition as an example,
> ``int(3) + int(4)`` is defined, and ``vector(1,2,3) + vector(3,4,5)``
> is defined, but ``int(3) + vector(3,4,5)`` doesn't make much sense.

In NumPy, this kind of operation makes sense we just broadcast int(3) to
the equivalent vector(3,3,3) and do the element-by-element operation.

This is how most array packages outside of Python do it as well.

I think adding the abstract base-classes for "algebras" is more 
complicated than has been discussed if you are going to start treating 
arrays as elements in their own algebra.  There is a lot of flexibility 
in how arrays can be viewed in an algebraic context.

The author gives a valiant go at defining base classes for generic 
algebras, but I didn't see everything I've encountered in my travels 
through algebra, and I don't understand the motivation for trying to 
include these things in Python specifically.

Therefore, I would stick with defining a hierarchy of numbers and leave 
it at that for now (if I even went that far).

For numbers, several suggestions have been offered.  In NumPy we use 
abstract base classes that look like this

Number
    Integer
       SignedInteger
       UnsignedInteger
    Inexact
       Floating
       ComplexFloating

But, this is because the array scalars in NumPy are based on 
C-data-types and not on general-purpose integers or floats.  In NumPy it 
is useful to check if you have an integer-typed array and so the 
base-classes become useful.

For general purpose Python, I would do something like

Complex
   Rational_Complex
     Integer_Complex
   Floating_Complex  # uses hardware float
   Decimal_Complex
   Real
     Rational
       Integer
     Floating        # uses hardware float
     Decimal


I don't like the "copied" structure which occurs because complex numbers 
can are isomorphic to a pair of reals but don't know else how to specify 
  a rational-complex number.


I also don't know if the decimal base-class includes un-limited 
precision floats (the analog of Python long integers) or if they must be 
fixed-precision.


-Travis