[SciPy-user] Mathematica Element-wise Multiplication

[Erik Volz]

There are several aspects of scipy that are counterintuitive to typical
users. Tranpose of 1D arrays is a big one. Another example is
z+=z.T # where dimension z > 1
which does not do what a naive user would think it does (try it).

I recently introduced very damaging bugs into my code by making both of
these mistakes; it took a long time for me to track down the problem. Of
course, the behavior is very logical from a developer's perspective, but the
veterans of this list have been very unsympathetic. At a minimum, there
should be warnings in the doc-strings about this behavior.

Erik Volz


From: Johann Cohen-Tanugi <cohen <at> slac.stanford.edu>

> Subject: Re: Mathematica Element-wise Multiplication<http://news.gmane.org/find-root.php?message_id=%3c47662A12.7060107%40slac.stanford.edu%3e>
> Newsgroups: gmane.comp.python.scientific.user<http://news.gmane.org/gmane.comp.python.scientific.user>
> Date: 2007-12-17 07:49:38 GMT (2 days, 16 hours and 31 minutes ago)
>
> Matthieu Brucher wrote:
> >
> >
> > 2007/12/17, Johann Cohen-Tanugi <cohen <at> slac.stanford.edu
> > <mailto:cohen <at> slac.stanford.edu>>:
> >
> >     thanks for these precisions, David. Reading it, I still come to think
> >     that it is a potential source of confusion to let a "row array" have a
> >     transpose or T method, that essentially does nothing.
> >
> >
> >
> > In object oriented code, this can happen often, but it is not a
> > problem. It does what you want : inverse the axis, even if there is
> > only one axis.
> hmmm...... okay... What I wanted was to transpose a 1D array into a
> vector, or vice-versa, with the linear algebra behavior in mind. I
> understand that numpy does not follow this, but I cannot believe that
> this behavior **is** what everybody wants! Tom's initial email was
> symptomatic, and Stefan's response, with the proposal to use the T
> method even more so!
>
> Assuming that this natural linear algebra could be retrieved when, and
> **only** when, the array is 1D, I do not see how such an implementation
> could break codes that depend on it, because I don't see why someone
> would call 'a.T' just to have 'a' again.... But it is probably my lack
> of imagination.
> Anyway, enough of this. I am sure the developers know better than me...
>
> cheers,
> Johann
>
> >
> >
> >     I guess there is a
> >     reason behind this situation, but given the fact that it is there,
> >     I am
> >     wondering whether T or transpose of a row array could in fact return
> >     what it is expected to, aka the 2d column array. Is there any
> >     reason not
> >     to have this functionality?
> >
> >
> >
> > More code in a simple function (thus slower) ? Breaking some code that
> > depend on it ? Not doing what the documentation says ?
> > I think the method should not be changed, it does exactly what it says
> > it does. Changing its behaviour because of Matlab is not a good
> > solution, Python is not Matlab.
> >
> > Matthieu
> > --
> > French PhD student
> > Website :
> http://matthieu-brucher.developpez.com/
> > Blogs : http://matt.eifelle.com <http://matt.eifelle.com> and
> > http://blog.developpez.com/?blog=92
> > LinkedIn :
> http://www.linkedin.com/in/matthieubrucher
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > SciPy-user mailing list
> > SciPy-user <at> scipy.org
> > http://projects.scipy.org/mailman/listinfo/scipy-user
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20071219/07e035bb/attachment.html>