On Wed, Apr 28, 2010 at 10:05 AM, Travis Oliphant
<oliphant@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