[Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)
Travis E. Oliphant
oliphant.travis at ieee.org
Thu Apr 26 12:28:14 CEST 2007
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
More information about the Python-3000
mailing list