About alternatives to Matlab

[Jon Harrop]

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