[Numpy-discussion] adding a .M attribute to the array.

[Perry Greenfield]

Travis Oliphant writes:
>
>
> .M  always returns a matrix for arrays < 2d, then we gain consistency.
>
> I've made this change and am ready to commit the change to the
> Numeric tree,
> unless there are strong objections.   I know some people do not like the
> proliferation of attributes, but in this case the notational
> convenience it
> affords to otherwise overly burdened syntax and the consistency it allows
> Numeric to deal with Matrix equations may be worth it.
>
> What do you think?
>
> -Travis Oliphant
>
>
I'd have to agree with Konrad and Paul on this one. While it makes simple
matrix expressions clearer, it opens a whole can of worms that were
discussed (and never resolved) a couple years ago. Suppose I do this:

x = a.M * libfunc(b.M, c.M)

where libfunc is a 3rd party module written in Python that was written
assuming that operators were elementwise operators. It may silently
do a matrix multiplication (depending on the shapes) instead of the
intended elementwise multiplication. Yet the usage above looks just as
legitimate as

x = a.M * b.M

In other words, it raises the issues of having incompatible modules, some
written with Numeric objects in mind, others with Matrix objects in mind.
Conceivably there will be modules useful for both kinds of objects. Do
we need to support two kinds? How do we deal with this?

This is still a problem if we don't allow the .M attribute but still have
widespread usage of a array object with different behavior for operations.
Unlike masked arrays, whose basic behavior is unchanged for "good" data,
the behavior for identical data is completely different.

I wish I had a good answer for this. I don't remember all of the past
suggestions, but it looks like one of the following solutions is needed:

1) Campaign for new operators in Python (various proposals to this affect.
   This is probably best from the Numeric point of view (maybe not from
   Python in general though).
2) Allow different array classes with different behavior, but come up with
   conventions and utilities for library developers to produce versions of
   arrays compatible with the convention assumed for the module (and convert
   back to the input type for output values). This doesn't prevent all
   opportunities for confusion and errors however. It also puts a stronger
   burden on library developers.
3) Do nothing and deal with the resulting mess. Perhaps the two camps have
   little need for each other's tools and it won't be much of a problem.
   Do option 2 retroactively if it is a problem.

Other suggestions?

Perry



Perry