[Caml-list] Ocaml for Scientific computing
Alex Mikhalev
I am wondering is anyone using Ocaml for scientific computing? I didn't
mean parsing, but for number crunching applications, like signal/image
analysis. Is it suitable for this kind of tasks in general? I would like
to hear from someone practically using it, not just theoretical
possibility.
I have read "Ocaml for Scientists" and although it gave me some very
good ideas, I didn't manage to repeat a number of examples with modules
from this book. I had a problem compiling or using scientific modules
(lacaml, fftw, some others) on linux and macosx and since some of these
modules look like someones graduate project, I would like to hear from
people practically using ocaml for mathematical simulations or analysis.
Preferable with OS, modules, problems encountered.
Regards,
Alex
_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Erik de Castro Lopo
> I am wondering is anyone using Ocaml for scientific computing?
Yes.
> I didn't
> mean parsing, but for number crunching applications, like signal/image
> analysis.
Yes. I'm working on code for audio digital signal processing and
function optimisation. I also wrote my own simple computer algebra
system.
> Is it suitable for this kind of tasks in general?
Much better than C or C++ or GNU Octave.
> I have read "Ocaml for Scientists" and although it gave me some very
> good ideas, I didn't manage to repeat a number of examples with modules
> from this book. I had a problem compiling or using scientific modules
> (lacaml, fftw, some others) on linux and macosx and since some of these
> modules look like someones graduate project,
I've looked at lacaml and didn't find any particular problems. The ocaml
fftw module was a little more problematic but I resolved the problem in
the end.
I would like to hear from
> people practically using ocaml for mathematical simulations or analysis.
> Preferable with OS, modules, problems encountered.
I'm doing this on Ubuntu Linux, I usually use package distributed by
Ubuntu but will compile my own from source if I need to.
HTH,
Erik
--
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"... the industrial-capitalist mode of software production
was doomed to be outcompeted from the moment capitalism
began to create enough of a wealth surplus for many
programmers to live in a post-scarcity gift culture."
-- Eric S. Raymond
Jon Harrop
> I've looked at lacaml and didn't find any particular problems. The ocaml
> fftw module was a little more problematic but I resolved the problem in
> the end.
I found Christophe's latest version fftw3 from sourceforge CVS to be easier to
use and very capable. One feature I would like is the ability to use ordinary
float or Complex.t arrays rather than big arrays. I'd also like better
integrated support for complex numbers in OCaml...
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?e
Hezekiah M. Carty
> Dear all,
> I am wondering is anyone using Ocaml for scientific computing? I didn't
> mean parsing, but for number crunching applications, like signal/image
> analysis. Is it suitable for this kind of tasks in general? I would like
> to hear from someone practically using it, not just theoretical
> possibility.
>
> I have read "Ocaml for Scientists" and although it gave me some very
> good ideas, I didn't manage to repeat a number of examples with modules
> from this book. I had a problem compiling or using scientific modules
> (lacaml, fftw, some others) on linux and macosx and since some of these
> modules look like someones graduate project, I would like to hear from
> people practically using ocaml for mathematical simulations or analysis.
> Preferable with OS, modules, problems encountered.
I am using OCaml for atmospheric/meteorological research. I started
using it about a year ago, and feel that it has been the right tool
for the job. My work so far has involved manipulating and analyzing
satellite data sets. OCaml has been quite fast computationally, and
the strict type checking and type inference have helped to eliminate
several sources of error.
I've used the OCaml GSL bindings and toyed around with some of the
plotting modules available (gnuplot, mlgrace, OVT, plplot,
camlimages, the included Graphics module). The code has been used
and developed under Ubuntu, Debian and CentOS. I currently use Godi
for my OCaml installation because it makes it easier to keep things
in my home directory if I don't have root access to a system.
The biggest problem I've faced with OCaml has been missing
libraries. The data I'm working with is (almost) all in HDF format,
so I had to write my own library bindings for OCaml. The other is
a library for plotting data - but that is largely due to a lack of
time spent on my part. That said, I've found writing bindings to C
libraries in OCaml much nicer than other languages I've tried.
An example of an older number crunching/scientific tool using OCaml
is Psilab - http://psilab.sourceforge.net/
However, it does not seem to be maintained by its author any more.
I have updated the code slightly so that it builds with newer GCC
versions if you have any interest in that.
Good luck with your work! I highly recommend OCaml, both for
selfish reasons - to bring more number-crunching oriented users in
to the community - and because it is an excellent tool for the job.
Hez
Jon Harrop
> The biggest problem I've faced with OCaml has been missing
> libraries. The data I'm working with is (almost) all in HDF format,
> so I had to write my own library bindings for OCaml. The other is
While this is a general purpose graphics library rather than a plotting
library, you may be interested in our hardware-accelerated vector graphics
library Smoke:
http://www.ffconsultancy.com/products/smoke_vector_graphics/?ol
Smoke makes it much easier to write visualization software.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?e
_______________________________________________
Markus E L
Jon Harrop wrote:
> On Tuesday 25 September 2007 17:11:31 Hezekiah M. Carty wrote:
>> The biggest problem I've faced with OCaml has been missing
>> libraries. The data I'm working with is (almost) all in HDF format,
>> so I had to write my own library bindings for OCaml. The other is
>> a library for plotting data...
>
> While this is a general purpose graphics library rather than a plotting
> library, you may be interested in our hardware-accelerated vector graphics
> library Smoke:
>
> http://www.ffconsultancy.com/products/smoke_vector_graphics/?ol
>
> Smoke makes it much easier to write visualization software.
Nothing against Smoke, but on a Unix/Linux platform it might just be
useful to use Ocaml to calculate the graphics data and pipe that to
another process, e.g. one of the well known scientific visualization /
graphing packages (starting with gnuplot, but there have been others
too). For practical work (not advertising), that spares one to do all
that tricky stuff like placing labels or ticks on the axis yourself.
BTW: What I'd consider a boon for scientific visualization, actually,
would be to output SVG to a file. Such an SVG file could be annotated
with a usual graphics editor like inkscape for publication: Very
valuable (if you don't need interactive visualization).
Regards -- Markus
Jon Harrop
> BTW: What I'd consider a boon for scientific visualization, actually,
> would be to output SVG to a file. Such an SVG file could be annotated
> with a usual graphics editor like inkscape for publication: Very
> valuable (if you don't need interactive visualization).
Absolutely. The full version of Smoke actually already does this but the free
version does not.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?e
_______________________________________________
Mike Lin
> Dear all,
> I am wondering is anyone using Ocaml for scientific computing? I didn't
> mean parsing, but for number crunching applications, like signal/image
> analysis. Is it suitable for this kind of tasks in general? I would like
> to hear from someone practically using it, not just theoretical
> possibility.
I use it for a lot of genome sequence processing, comparative genomics
and phylogenetic modeling. Algorithmically this involves conditional
random fields (for which I have my own library) and some linear
algebra and numerical optimization (for which I use Lacaml and
ocamlgsl). I had a lot of frustrations at first, but it's been better
since we got exception stack traces and ocaml+twt.
For numerical computing, I wish ocamlopt would do at least basic loop
optimizations, like hoisting invariant values -- this type of stuff is
easily done manually, but often at the expense of code readability. I
can see how this may be a bottomless pit for the dev team though,
since I would probably always feel like we are one crucial
optimization short of not having to rewrite that tight loop in C.
In any case though, I work in a group where everyone else uses Python,
so I'm already beating their pants off :o)
Mike
Hezekiah M. Carty
> BTW: What I'd consider a boon for scientific visualization, actually,
> would be to output SVG to a file. Such an SVG file could be annotated
> with a usual graphics editor like inkscape for publication: Very
> valuable (if you don't need interactive visualization).
This is one of the things about the OCaml Visualization Toolkit
(one of the Jane St. summer projects). It is built around
cairo-ocaml, which in turn supports SVG output.
OVT is still somewhat incomplete, but its output is already quite
attractive thanks to the Cairo backend. SVG output is one of the
items still missing from OVT, and I do not know what plans exist to
maintain this library. But with that addition it would be an
immensely useful tool for scientific plots, among other things.
I've already used OVT for a few simple presentation figures.
Hez
skaller
> On Sep 25, 7:11 am, Alex Mikhalev <a.mikha...@cranfield.ac.uk> wrote:
> For numerical computing, I wish ocamlopt would do at least basic loop
> optimizations, like hoisting invariant values -- this type of stuff is
> easily done manually, but often at the expense of code readability.
Gcc does this quite well I think. However in a higher level
procedural language (like Ocaml and Felix) it is very hard
to get right and potentially very expensive.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
Jon Harrop
> On Tue, 2007-09-25 at 13:27 -0400, Mike Lin wrote:
> > On Sep 25, 7:11 am, Alex Mikhalev <a.mikha...@cranfield.ac.uk> wrote:
> >
> > For numerical computing, I wish ocamlopt would do at least basic loop
> > optimizations, like hoisting invariant values -- this type of stuff is
> > easily done manually, but often at the expense of code readability.
>
> Gcc does this quite well I think. However in a higher level
> procedural language (like Ocaml and Felix) it is very hard
> to get right and potentially very expensive.
I'm not sure that it is conceptually more difficult to do similar things for
OCaml but my vote goes to hoisting bounds checks. I don't like having to
write unsafe code by hand in OCaml and F# does a great job of improving
performance by hoisting bounds checks.
I discussed some of the benchmarks where F# is faster than OCaml recently on
one of our blogs:
http://ocamlnews.blogspot.com/2007/09/spectral-norm.html
For some reason, the current implementation of spectral-norm on the shootout
leaves out some important optimizations in OCaml. F# doesn't require these
optimizations to be done by hand.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?e
_______________________________________________
skaller
> I'm not sure that it is conceptually more difficult to do similar things for
> OCaml but my vote goes to hoisting bounds checks. I don't like having to
> write unsafe code by hand in OCaml and F# does a great job of improving
> performance by hoisting bounds checks.
I guess that this is easier. How much speed is gained eliding
bounds checks?
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
_______________________________________________
Jan Kybic
> mean parsing, but for number crunching applications, like signal/image
> analysis. Is it suitable for this kind of tasks in general? I would like
> to hear from someone practically using it, not just theoretical
> possibility.
I have used Ocaml for several projects involving numerical
calculations, including image processing, boundary element methods and
optimization. I use Lacaml, fftw, MPI and Gsl libraries, the
installation was not difficult. Ocaml has performed very well for me
so far, it is faster than Python or Matlab and more "friendly" than
C/C++. Some minor issues:
- There is too many different representations of vectors and matrices:
float arrays, plain big arrays, Lacaml Fortran style big arrays,
several kinds of Gsl vectors with yet separate styles. I found I
often had to convert vectors or matrices from one format to another
because the function I wanted to use was available for a different
interface.
- Limited interactivity - it would help if you could call native compiled
modules from the toplevel.
- Limited debugging - it is not possible to debug compiled modules.
I would like to see an interface to gdb (I work on Linux), or a
possibility for the byte compiled code being debugged to call
natively compiled modules.
- I still find Ocaml object system less natural for me and more
limiting than for example Python's. Also, often you can do the same
thing with the objects as with the module system, so the choice of the
best design pattern is sometimes not obvious at the first sight and
requires a lot of foresight. But I assume this is just a matter of
practice.
Good luck,
Jan
--
-------------------------------------------------------------------------
Jan Kybic <ky...@fel.cvut.cz> tel. +420 2 2435 5721
http://cmp.felk.cvut.cz/~kybic ICQ 200569450
Florian Hars
> I guess that this is easier. How much speed is gained eliding
> bounds checks?
It may even make the code slower:
http://caml.inria.fr/pub/ml-archives/caml-list/2004/01/679987f7b8b70e4cd9f088ac4e6c8097.en.html
Yours, Florian.
skaller
> skaller schrieb:
> > I guess that this is easier. How much speed is gained eliding
> > bounds checks?
>
> It may even make the code slower:
>
> http://caml.inria.fr/pub/ml-archives/caml-list/2004/01/679987f7b8b70e4cd9f088ac4e6c8097.en.html
Yes, I tend to agree with Xavier's analysis.
This may also explain why C code generated by Felix is
often faster than hand written C code: on AMD64 Felix
generated C code for Ackermann's function is almost the same
as the hand written C, but runs 2x faster, and 2.5x faster
than Ocamlopt generated code.
At this point with gcc as the compiler and using stack
programming (no heap), I'm now expecting Felix to beat
C on all programs (and if it doesn't it's a bug
in the compiler that needs fixing).
I am guessing this is because GCC has good SSA analysis,
and it works a lot better on goto spaghetti with a fixed
stack frame of the kind Felix tends to generate, than
block structured C code using for loops, etc.
So I'd add to Xaviers comments on processor behaviour
that small differences in source code structure can make
a big difference to compiler technology.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
_______________________________________________