Carl Banks wrote: > No, they're never redefined (even in the recursive version). Slices of > them are reassigned. That's a big difference.
I see. > (Actually, it does create a temporary array to store the intermediate > result, but that array does not get bound to odd.) Sure. >> In particular, I think you are eagerly >> allocating arrays when, in a functional language, you could just as >> easily compose closures. > > You are completely wrong. I'll give an example. If you write the Python: a[:] = b[:] + c[:] + d[:] I think that is equivalent to the ML: fill a (map2 ( + ) (map2 ( + ) b c) d) which can be deforested in ML to avoid the creation of the intermediate result b[:] + c[:] by using a closure to add three values at once: fill a (map3 (fun b c d -> b + c + d) b c d) which will be much faster because it doesn't generate an intermediate array. > This data sharing more or less accomplishes the same thing that the > "closures" you speak of accomplish (in this case), only without the > functional. The closure avoided the intermediate result. You said that the Python isn't doing that? > It's not correct, but what you left out is probably low cost. > > OCaml is compiled to machine code, right? Yes. > And types can be inferred at compile time, correct? Types are completely inferred at compile time. > Well then of course it's faster. Yes. So this doesn't seem to be a killer example of numpy, although I am still amazed that it can outperform Matlab. > It seems to > me a big help is the ability to fold multiple array operations into a > single loop, which is optimization a dynamically-typed language like > Python can't easily make. (It'd require are really smart JIT compiler > or some concessions in dynamicity.) Writing a JIT to compile this kind of stuff is easy. My point is that this is fundamentally bad code, so why bother trying to write a Python JIT? Why not just write in a better language for this task? Optimising within a fundamentally slow language seems silly to me. -- Dr Jon D Harrop, Flying Frog Consultancy Objective CAML for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists -- http://mail.python.org/mailman/listinfo/python-list
