[Numpy-discussion] [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)
Wed Apr 25 11:50:20 CDT 2007
[bcc'ing numpy-discussion. Comments should probably try to stay on the
On 4/25/07, Josiah Carlson <email@example.com> wrote:
> Are the base number operations in Python all that difficult to
> understand? Do we really need to add mathematical formalism into
> Python's type system before people understand the meaning of X * Y?
> Because all I really see this doing is confusing the hell out of people
> who aren't mathematicians; I'm a theoretical computer scientist and I
> had to try to think for a moment to verify that all of those were really
> necessary to separate the cases.
> I really do understand wanting to be able to ask "is operation X
> supported for values Y and Z", but is this really necessary for numbers?
If you don't want to use the full power of the system, nothing forces
you to. If someone doesn't know what a Ring or a complex number is,
they can just check for Real and rely on the same operations, at the
small cost of overconstraining their inputs. One reason I'm suggesting
splitting the classes into the "algebra" and "numbers" modules is so
that people who don't know or care about the algebra can rely on just
"numbers" and still get nearly all of the benefits.
However, I think it's important to provide a framework for people who
want to do more powerful things. If you write a function that can take
an arbitrary ring, it should Just Work on a python int, or any other
Complex subclass, without you having to check for a lot of operations
separately. The Haskell98 numerical hierarchy actually does start at
Num, ignoring the algebraic structures underneath, and it draws a lot
of criticism for it.
That does mean that the names and documentation in the numbers module
need to be as clear as we can make them for non-mathematical
audiences. I'm certainly open to suggestions on that front.
More information about the Numpy-discussion