[Numpy-discussion] Numpy and PEP 343
ndarray at mac.com
Tue Feb 28 17:51:20 CST 2006
Lazy evaluation has been part of many array languages since early days
of APL (which makes this idea almost 50 years old). I was
entertaining an idea of bringing lazy evaluation to python myself and
concluded that there are two places where it might fit
1. At the level of python optimizer a * x + y, for example, can be
translated into a call to a call to axpy if a, x and y are known to be
arrays. This aproach quickly brings you to the optional static
typing idea. <http://www.artima.com/weblogs/viewpost.jsp?thread=85551>
2. Overload arithmetic operators for ufunc objects. This will allow
some form of tacit programming
<http://elliscave.com/APL_J/IversonAPL.htm> and you would be able to
f = multiply + multiply
f(x, y, z, t)
and have it evaluated without temporaries. Both of these ideas are
from the pie-in-the-sky variety.
On 2/28/06, Paul F. Dubois <paul at pfdubois.com> wrote:
> You're reinventing C++ expression templates, although since Python is
> dynamically typed you don't need templates. The crucial feature in C++
> that lets it all work is that you can override the action for assignment.
> a = b*c + d*e
> If we could realize we were at the "equals" sign we could evaluate the
> RHS, and assign it to a.
> This is not possible in Python; to make is possible would require
> slowing down regular assignment, which is perhaps a definition of bad.
> a[...] = RHS
> could be overridden but it is ugly and 'naive' users will forget.
> a := RHS
> could be added to the language with the semantics that it tries to do
> a.__assignment__(RHS) but Guido told me no long ago. (:->. Also, you
> might forget the : in :=.
> would also work but then the original statement would produce a strange
> object with surprising results.
> David M. Cooke wrote:
> > Tim Hochberg <tim.hochberg at cox.net> writes:
> >> <pie-in-the-sky>
> >> An idea that has popped up from time to time is delaying evalution of
> >> a complicated expressions so that the result can be computed more
> >> efficiently. For instance, the matrix expression:
> >> a = b*c + d*e
> >> results in the creation of two, potentially large, temporary matrices
> >> and also does a couple of extra loops at the C level than the
> >> equivalent expression implemented in C would.
> >> The general idea has been to construct some sort of psuedo-object,
> >> when the numerical operations are indicated, then do the actual
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
More information about the Numpy-discussion