<br><br><div><span class="gmail_quote">On 8/21/07, <b class="gmail_sendername">Anne Archibald</b> <<a href="mailto:peridot.faceted@gmail.com">peridot.faceted@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

On 21/08/07, Timothy Hochberg <<a href="mailto:tim.hochberg@ieee.org">tim.hochberg@ieee.org</a>> wrote: > This is just a general comment on recent threads of this type and not > directed specifically at Chuck or anyone else.

<br>><br>> IMO, the emphasis on avoiding FOR loops at all costs is misplaced. It is<br>> often more memory friendly and thus faster to vectorize only the inner loop<br>> and leave outer loops alone. Everything varies with the specific case of

<br>> course, but trying to avoid FOR loops on principle is not a good strategy.<br><br>Yes and no. From a performance point of view, you are certainly right;<br>vectorizing is definitely not always a speedup. But for me, the main

<br>advantage of vectorized operations is generally clarity: C = A*B is<br>clearer and simpler than C = [a*b for (a,b) in zip(A,B)]. When it's<br>not clearer and simpler, I feel no compunction about falling back to<br>

list comprehensions and for loops. </blockquote><div> I always assume that in these cases performance is a driver of the question. It would be straightforward to code an outer equivalent in Python to hide this for anyone who cares. Since no one who asks these questions ever does, I assume they must be primarily motivated by performance.

<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">That said, it would often be nice to have something like<br>map(f,arange(10)) for arrays; the best I've found is

vectorize(f)(arange(10)). vectorize, of course, is a good example of my point above: it really just loops, in python IIRC, </blockquote><div> I used to think that too, but then I looked at it and I believe it actually grabs the code object out of the function and loops in C. You still have to run the code object at each point though so it's not that fast. It's been a while since I did that looking so I may be totally wrong.

<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">but conceptually it's extremely handy for<br>doing exactly what the OP wanted. Unfortunately vectorize() does not

<br>yield a sufficiently ufunc-like object to support .outer(), as that<br>would be extremely tidy.</blockquote><div><br>I suppose someone should fix that someday. However, I still think vectorize is an attractive nuisance in the sense that someone has a function that they want to apply to an array and they get sucked into throwing vectorize at the problem. More often than not, vectorize makes things slower than they need to be. If you don't care about performance, that's fine, but I live in fear of code like:

def f(a, b):        return sin(a*b + a**2)    f = vectorize(f)    The original function f is a perfectly acceptable vectorized function (assuming one uses numpy.sin), but now it's been replaced by a slower version by passing it through vectorize. To be sure, this isn't always the case; in cases where you have to make choices, things get messier. Still, I'm not convinced that vectorize doesn't hurt more than it helps.

<br><br></div><br></div><br>-- <br>.  __<br>.   |-\<br>.<br>.  <a href="mailto:tim.hochberg@ieee.org">tim.hochberg@ieee.org</a>