[Numpy-discussion] proposing a "beware of [as]matrix()" warning
Wed Apr 28 11:19:26 CDT 2010
On Wed, Apr 28, 2010 at 11:05, Travis Oliphant <email@example.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
>> mine who ported code over from MATLAB, I am seeing an ugly melange of
>> matrix objects and ndarrays that are interacting poorly with each
>> and various functions in SciPy/other libraries. In particular there
>> 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
> 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"
> A proposal was made to allow "calling a NumPy array" to infer dot
> a(b) is equivalent to dot(a,b)
> a(b)(c) would be equivalent to dot(dot(a,b),c)
> This seems rather reasonable.
> 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?
There is currently a moratorium on language changes. This will have to wait.
"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
-- Umberto Eco
More information about the NumPy-Discussion