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

[Guido van Rossum]

On 4/25/07, Jeffrey Yasskin <jyasskin at gmail.com> wrote:
> On 4/25/07, Guido van Rossum <guido at python.org> wrote:
> > Jeffrey, is there any way you can drop the top of the tree and going
> > straight from Number to Complex -> Real -> Rational -> Integer? These
> > are the things that everyone with high school math will know.
>
> I think yes, if you can confirm that the
>     import numbers
>     class Ring(AdditiveGroup): ...
>     numbers.Complex.__bases__ = (Ring,) + numbers.Complex.__bases__
> hack I mention under IntegralDomain will make isinstance(int, Ring) return True.

Hm... That would require built-in types to be mutable (by mere
mortals) which would kill the idea of multiple interpreters. AFAIK the
only user of multiple interpreters is mod_python, which is a pretty
popular Apache module... (Google claims 1.8M hits, vs. 5.66M for
mod_perl, the market leader.)

I guess the alternative would be to keep the mathematical ones in but
make it so that mere mortals (among which I count myself :) never need
to know about them. Sort of like metaclasses, for most people.

But this still presents a bit of a problem. If we insist that built-in
types are immutable, whenever a mathematician needs a new kind of
algebraic category (you mention a few in the PEP), they have no way to
declare that int or float are members of that category. They could
write things like

class MyFloat(float, DivisionRing): pass

but this would be fairly painful. I would like to let users modify the
built-ins, but such changes ought to be isolated from other
interpreters running in the same address space. I don't want to be the
one to tell the mod_python community they won't be able to upgrade to
3.0...

> Do you want "Number" to be equivalent to Ring+Hashable (or a
> Haskell-like Ring+Hashable+__abs__+__str__)? I don't think a "Number"
> class is strictly necessary since people can check for Complex or Real
> directly, and one of those two is probably what they'll expect after
> knowing that something's a number.

Fair enough, you could start with Complex.

> Also, I don't see much point in putting Rational between Real and
> Integer. The current hierarchy is Real (int, float, Decimal, rational)
> :> Integer (int) and Real :> FractionalReal (float, Decimal,
> rational), but Integer and FractionalReal are just siblings.

Why? Why not have a properfraction() on Integer that always returns 0
for the fraction? The current math.modf() works just fine on ints
(returning a tuple of floats).

And why distinguish between Real and FractionalReal? What's the use
case for reals that don't know how to compute their fractional part?

> I'm wondering how many people are writing new numeric types who don't
> know the abstract algebra.

It's easy to know the algebra without recalling the terminologies.
Lots of programmers (myself included!) are largely self-taught.

> I think we should be able to insulate
> people who are just using the types from the complexities underneath,
> and the people writing new types will benefit. Or will seeing "Ring"
> in a list of superclasses be enough to confuse people?

Shouldn't only mathematicians be tempted to write classes deriving
from Ring? Everyone else is likely to subclass one of the more
familiar types, from Complex onwards.

PS. I've checked your PEP in, as PEP3141. We might as well keep a
fairly complete record in svn, even if we decide to cut out the
algebraic foundational classes.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)