[Numpy-discussion] Re: [Python-Dev] Re: Numeric life as I see it

[David Ascher]

On Wed, 09 Feb 2005 22:02:11 -0700, Travis Oliphant <oliphant at ee.byu.edu> wrote:

GvR:
>And why would a Matrix need to inherit from a C-array? Wouldn't it
>make more sense from an OO POV for the Matrix to *have* a C-array
>without *being* one?

Travis:
> The only reason I'm thinking of here is to have it inherit from the
> C-array many of the default methods without having to implement them all
> itself.   I think Paul is saying that this never works with C-types like
> arrays, and I guess from your comments you agree with him.
> 
> The only real reason for wanting to construct a separate Matrix object
> is the need to overload the * operation to do matrix multiplication
> instead of element-by-element multiplication.

This is dredging stuff up from years (and layers and layers of new
memories =), but I think that what Paul was referring to was in fact
independent of implementation language.

The basic problem, IIRC, had to do with the classic (it turns out)
problem of confusing the need for reuse of implementation bits with
interface inheritance.  We always felt that things that people felt
were "array-like" (Matrices, missing value arrays, etc.) _should_
inherit from array, and that (much like you're saying), it would save
work.  In practice, however, there were a few problems (again, from
lousy memory), all boiling down to the fact that the array object
implemenation implies interfaces that weren't actually applicable to
the others.  The biggest problems had to do with the fact that when
you do subclassing, you end up in a nasty combinatorial problem when
you wanted to figure out what operand1 operator operand2 means, if
operand1 is a derivative and operand2 is a different derivative.  In
other words, if you multiply a matrix with a missingvalues array, what
should you do?  Having a common inheritance means you need to _stop_
default behaviors from happening, to avoid meaningless results.  It
gets worse with function calls that take "array-like objects" as
arguments.

A lot of this may be resolvable with the recent notions of adaptation
and more formalized interfaces.  In the meantime, I would, like Paul,
recommend that you separate the interface-bound type aspects (which is
what Python classes are in fact!) from the implementation sharing.

This may be obvious to everyone, and if so, sorry.

--david