# [Numpy-discussion] big picture? One proposal

Perry Greenfield perry at stsci.edu
Thu Mar 7 17:29:02 CST 2002

```Eric makes a good point about stepping back and thinking about these
issues in a broader context. Along these lines I'd like to make
a proposal and see what people think. I think Konrad made a very
good point about matrix vs array representation. If we made it illegal
to combine them in expressions without explicit conversions, we could
prevent much confusion about what kind of operations would be performed.
An attempt to use one kind of in place of an other would trigger
an exception and thus users would always know when that was a problem.
Implementing this behavior in numarray would be simple, as would having
both share the same implementation for common operations (without any
extra performance penalty).

That still leaves the question of how to do the conversions, i.e., one
of the following options

matrix(a) * b  # matrix multiply of array (a) with matrix (b)
a.M * b
a.M() * b

likewise:

a * array(b)   # element-wise multiply of array (a) with matrix (b)
a * b.A
a * b.A()

I strongly prefer the first (functional) form.

Rick White has also convinced me that this alone isn't sufficient.
There are numerous occasions where people would like to use matrix
multiply, even in a predominately "array" context, enough so that this
would justify a special operator for matrix multiplication. If the
Numeric community is united on this, I think Guido would be receptive.
We might suggest a particular operator symbol or pair (triple) but
leave him some room to choose alternatives he feels are better for
Python (he could well come up with a better one). It would be nice
if it were a single character (such as @) but I'd be happy with many
of the other operator suggestions (~*, (*), etc.)

Note that this does not imply we don't need a seperate matrix object.
I think it is clear that simply providing a matrix multiply operator
is not going to answer all their needs.

As to the other related issues that Eric raises, in particular:
operators for transpose and complex conjugate, I guess I don't see
these as so important. Both of these are unary operators, and as such
either of the following options does not seem to be notationally much
worse (whereas using binary functions in place of binary operators is
much less readable)

transpose(x)    conjugate(x)
x.transpose()   x.conjugate()
x.T()           x.C()
x.T             x.C

(Personally, I prefer the first two)

Perry

```

More information about the Numpy-discussion mailing list