Timothy Hochberg wrote:

On 4/18/07, *Sturla Molden* mailto:sturla@molden.no> wrote:

On 4/18/2007 7:33 AM, Anne Archibald wrote:

>copying. And the scope of improvement would be very limited; an expression like A*B+C*D would be much more efficient, probably, if the whole expression were evaluated at once for each element (due to memory locality and temporary allocation). But it is impossible for numpy, sitting inside python as it does, to do that.

Most numerical array/matrix libraries dependent on operator overloading generates temporaries. That is why Fortran is usually perceived as superior to C++ for scientific programming. The Fortran compiler knows about arrays and can avoid allocating three temporary arrays to evaluate and expression like

y = a * b + c * d [SNIP]

I'd really like to see a Python extension library do this one day. It would be very cool and (almost) as efficient as plain Fortran - though not quite, we would still get some small temporary objects created. But that is a sacrifice I am willing to pay to use Python. We would gain some efficacy over Fortran by postponing indefinitely evaluation of computations that are not needed, when this is not known at compile time.

Any comments?

I periodically wonder if something like this could be built on top of numexpr without too much pain. Simply build up the expression on operations and then evaluate when data is requested. You'd need some sort of Jekyl & Hyde matrix that spent the first part of it's life unevaluated and then converted itself to something very much like an array when it evaluated itself. If might end up being tricky to make sure that everything got transparently evaluated at the right time though.

I've never had time to try it though.

Sturla Molden Ph.D.

Hi, Correct me if I'm wrong but it is not possible to code something working like boost++ in python. It is due to the fact we cannot overload the = operator in python. As a result you cannot implement the way boost++ works : + * - / operators build a tree and all the loops are done in the = operator code. I do not say that it is impossible to code an efficient way to deal with operators and matrix in python but only that it looks not possible to match the boost++ way of thinking. Comments? Xavier -- ############################################ Xavier Gnata CRAL - Observatoire de Lyon 9, avenue Charles André 69561 Saint Genis Laval cedex Phone: +33 4 78 86 85 28 Fax: +33 4 78 86 83 86 E-mail: gnata@obs.univ-lyon1.fr ############################################

Sturla Molden wrote:

...

Timothy Hochberg wrote:

...

Correct me if I'm wrong but it is not possible to code something working like boost++ in python. It is due to the fact we cannot overload the = operator in python. As a result you cannot implement the way boost++ works : + * - / operators build a tree and all the loops are done in the = operator code.

I do not say that it is impossible to code an efficient way to deal with operators and matrix in python but only that it looks not possible to match the boost++ way of thinking.

I have three comments:

1. Boost++ depends on template metaprogramming. For this to work, array bounds must be known in advance. If you don't know the dimensions in advance, the compiler cannot get rid of the temporary storage and redundant loops. Basically, Boost++ and Blitz++ can be efficient for small tight loops. But for small arrays, Boost++ and Blitz++ can do miracles.

2. Template metaprogramming and symbolic maths are very different subjects. Evaluating symbols run-time is very different for evaluating templates compile-time. If you know the eval() function in Python and Lisp it is probably easier to understand what I suggested; eval() and Lisp macros are not generally understood by the C++ community.

3. My suggestion did not require overloading the assignment operator (=). I suggested to let the "Jekyll & Hyde array" evaluate itself when it's content is requested (e.g. using the indexing operator [] as one such signal). Actually, not overloading the assignment operator is important as it allows us to procrastinate evaluation of expressions as long as we can. It may seem strange, but it is an important optimization technique. The things you don't do don't take any time.

yes yes and yes :). I don't know if I'm a python or a c++ programmer but I fully understand what eval() is. eval() is not evil in a python/lisp context. Not at all! I do like to have the capability to play with str and eval in python (I also do like template meta prog...) My point was only to say that the way to provide the user with this lazzy operators can't be the same as in c++. Sorry if my message was not clear :(. What you want is symbolics maths with matrix and a way to trigger the evaluation. Well, as far as I have seen for now, it looks pretty hard to code that with a pythonic syntax and a way to report in case of errors. It is also pretty hard to avoid nasty infinite recursions playing with "to be evaluated objects". I'm going to have a look to this scipy sandbox module. Xavier -- ############################################ Xavier Gnata CRAL - Observatoire de Lyon 9, avenue Charles André 69561 Saint Genis Laval cedex Phone: +33 4 78 86 85 28 Fax: +33 4 78 86 83 86 E-mail: gnata@obs.univ-lyon1.fr ############################################