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

[Todd Alan Pitts, Ph.D.]

I often (perhaps inappropriately) fall into the "silent user"
category.  However, many of those in this conversation have put
significant effort into python development and the least I can do is
offer a comment from the standpoint of someone who uses python and
Numeric extensively.  Perhaps I am stepping into the middle of a
conversation here -- I hope I have read all the relevant material.
People may "like" Matlab syntax because it requires less typing or
because it pleases them aesthetically.  I personally feel that explicit
function based operators (like transpose()) are very clear and
unambiguous.  While I understand the desire to have the code and the
"math" look similar I think, in general, this is leads to the same
kind of difficulty one has with notation in mathematics -- Notation
that works well in some fields is extremely cumbersome in others.  I
don't expect it to look like an equation. I find orderly, predictable
behavior that doesn't send me to the source code too often to figure
out what is happening very helpful.  Treating 1d or 2d arrays as
matrices is admittedly *very* useful in some applications but
cumbersome in others.  This problem is reminiscent of the "clash"
between the PIL and Numeric modules or between the C-language
row-major matrix storage format and the (in my opinion) better thought
out FORTRAN column-major matrix storage format.  These differences
place limitations on the potential for synergistic profits in the
project.  It is my personal experience/opinion that "convenience"
methods are best added in a specific application that is not intended
to be released generally.

-Todd







* Perry Greenfield (perry at stsci.edu) wrote:
> 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
> 
> 
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion