About alternatives to Matlab

Konrad Hinsen konrad.hinsen at laposte.net
Wed Dec 6 05:52:12 EST 2006


On Dec 5, 2006, at 16:35, Mark Morss wrote:

> very well-written) _Practical OCaml_.  However, I also understand that
> OCaml supports only double-precision implementation of real numbers;
> that its implementation of arrays is a little clunky compared to
> Fortran 95 or Numpy (and I suspect not as fast as Fortran's); and that
> the available libraries, while powerful, are by no means as
> comprehensive as those available for Python.  For example, I am  
> unaware
> of the existance of an HDF5 interface for OCaml.

OCaml is a popular language with computer scientists in France (not  
surprisingly, given its origins), and I have regular contacts with  
the computer science research community, so I have been exposed quite  
a bit to OCaml, to the point of once considering it for numerical  
work. Not as a replacement for Python, but as a replacement for C or  
Fortran, i.e. for the heavy-duty parts of my work.

What made me abandon this idea are mainly two points:
1) the lack of polymorphism
2) the difficulty of interfacing to C and Fortran code
3) the limited processor support of the native code compiler

The lack of polymorphism, particularly in operators, makes OCaml code  
a pain to write and read in my opinion. Float arithmetic is already  
bad enough, with "+." etc. everywhere. If I add complex and vector  
types (which could easily be defined in OCaml), I'd have to come up  
with two more sets of arithmetic operators that make my code less  
readable. In addition, I'd either have to keep multiple  
implementations for many algorithms, or pass in all operators and  
mathematical functions as arguments. Neither solution is acceptable  
for me.

Interfacing to C and Fortran code is important because that's what  
most libraries are written in. While it is possible in principle with  
OCaml, it is (or at least was at the time I looked) a pain to  
interface typical array-handling code, for lack of a compatible data  
structure on the OCaml side.

Native code compilation is obviously important for speed. While many  
popular processors are supported by ocamlopt, scientific users are  
notorious for grabbing whatever fast hardware they can lay their  
hands on. It seems safe to count on the GNU suite being ported  
rapidly to any new platform. I don't have as much faith in the OCaml  
developers, though perhaps just out of ignorance.

Konrad.




More information about the Python-list mailing list