Lazy evaluation: overloading the assignment operator?

sturlamolden sturlamolden at yahoo.no
Wed May 2 15:15:44 EDT 2007


Python allows the binding behaviour to be defined for descriptors,
using the __set__ and __get__ methods. I think it would be a major
advantage if this could be generalized to any object, by allowing the
assignment operator (=) to be overloaded.

One particular use for this would be to implement "lazy evaluation".
For example it would allow us to get rid of all the temporary arrays
produced by NumPy.

For example, consider the expression:

 y = a * b + c * d

If this expression is evaluated bya Fortran 90/95 compiler, it will
automatically generate code like

do i = 1,n
   y(i) = a(i) * b(i) + c(i) * d(i)
enddo

On the other hand, conventional use of overloaded binary operators
would result in something like this:

allocate(tmp1,n)
do i = 1,n
   tmp1(i) = a(i) * b(i)
enddo
allocate(tmp2,n)
do i = 1,n
   tmp2(i) = c(i) * d(i)
enddo
allocate(tmp3,n)
do i = 1,n
   tmp3(i) = tmp1(i) + tmp2(i)
enddo
deallocate(tmp1)
deallocate(tmp2)
do i = 1,n
   y(i) = tmp3(i)
enddo
deallocate(tmp3)

Traversing memory is one of the most expensive thing a CPU can do.
This approach is therefore extremely inefficient compared with what a
Fortran compiler can do.

However, if we could overload the assignment operator, there would be
an efficient solution to this problem. Instead of constructing
temporary temporary arrays, one could replace those with objects
containing lazy expressions "to be evaluated sometime in the future".
A statement like

 y = a * b + c * d

would then result in something like this:

tmp1 = LazyExpr('__mul__',a,b) # symbolic representation of "a * b"
tmp2 = LazyExpr('__mul__',c,d) # symbolic representation of "c * d"
tmp3 = LazyExpr('__add__',tmp1,tmp1) # symbolic "a * b + c * d"
del tmp1
del tmp2
y = tmp3 # tmp3 gets evaluated as assignment is overloaded


Should there be a PEP to overload the assignment operator? In terms of
syntax, it would not be any worse than the current descriptor objects
- but it would make lazy evaluation idioms a lot easier to implement.



Sturla Molden




More information about the Python-list mailing list