[Numpy-discussion] proposing a "beware of [as]matrix()" warning

[Charles R Harris]

On Wed, Apr 28, 2010 at 10:05 AM, Travis Oliphant <oliphant at enthought.com>wrote:

>
> On Apr 26, 2010, at 7:19 PM, David Warde-Farley wrote:
>
> > Trying to debug code written by an undergrad working for a colleague
> > of
> > mine who ported code over from MATLAB, I am seeing an ugly melange of
> > matrix objects and ndarrays that are interacting poorly with each
> > other
> > and various functions in SciPy/other libraries. In particular there
> > was
> > a custom minimizer function that contained a line "a * b", that was
> > receiving an Nx1 "matrix" and a N-length array and computing an outer
> > product. Hence the unexpected 6 GB of memory usage and weird
> > results...
>
> Overloading '*' and '**' while convenient does have consequences.   It
> would be nice if we could have a few more infix operators in Python to
> allow separation of  element-by-element calculations and "dot-product"
> calculations.
>
> A proposal was made to allow "calling a NumPy array" to infer dot
> product:
>
> a(b) is equivalent to dot(a,b)
>
> a(b)(c) would be equivalent to dot(dot(a,b),c)
>
> This seems rather reasonable.
>
>
I like this too. A similar proposal that recently showed up on the list was
to add a dot method to ndarrays so that a(b)(c) would be written
a.dot(b).dot(c).


> While I don't have any spare cycles to push it forward and we are
> already far along on the NumPy to 3.0, I had wondered if we couldn't
> use the leverage of Python core developers wanting NumPy to be ported
> to Python 3 to actually add a few more infix operators to the language.
>
> One of the problems of moving to Python 3.0 for many people is that
> there are not  "new features" to outweigh the hassle of moving.
> Having a few more infix operators would be a huge incentive to the
> NumPy community to move to Python 3.
>
> Anybody willing to lead the charge with the Python developers?
>
>
Problem is that we couldn't decide on an appropriate operator. Adding a
keyword that functioned like "and" would likely break all sorts of code, so
it needs to be something that is not currently seen in the wild.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20100428/c339b63e/attachment.html>