Lazy evaluation: overloading the assignment operator?

[sturlamolden]

On May 2, 11:08 pm, "Diez B. Roggisch" <d... at nospam.web.de> wrote:

> And AFAIK the general overhead of laziness versus eager evaluation does
> not pay off - haskell is a tad slower than e.g. an ML dialect AFAIK.

In the numerical Python community there is already a prototype
compiler called 'numexpr' which can provide efficient evaluation of
expressions like y = a*b + c*d. But as long as there is no way of
overloading an assignment, it cannot be seamlessly integrated in an
array framework. One will e.g. have to type up  Python expressions as
strings and calling eval() on the string instead of working directly
with Python expressions.

In numerical work we all know how Fortran compares with C++. Fortran
knows about arrays and can generate efficient code. C++ doesn't and
have to resort to temporaries returned from overloaded operators. The
only case where C++ can compare to Fortran is libraries like Blitz++,
where for small fixes-sized arrays the temporary objects and loops can
be removed using template meta-programming and optimizing compilers.
NumPy has to generate a lot of temporary arrays and traverse memory
more than necessary. This is a tremendous slow down when arrays are
too large to fit in the CPU cache. Numexpr deals with this, but Python
cannot integrate it seamlessly. I think it is really a matter of what
you are trying to do. Some times lazy evaluation pays off, some times
it doesn't.

But overloaded assignment operators have more use than lazy
evaluation. It can be used and abused in numerous ways. For example
one can have classes where every assignment results in the creation of
a copy, which may seem to totally change the semantics of Python code
(except that it doesn't, it's just an illusion).


Sturla Molden