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

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