Not Rocket Science

Not Rocket Science

[Jon Harrop]

I stumbled upon the following blog post by Alexander Mikhalev:

  "Why ocaml and haskell is not for scientists" -
http://alexandermikhalev.blogspot.com/2008/01/why-ocaml-and-haskell-is-not-for.html

Alex is kind enough to say that he was impressed with the demos from my 
book "OCaml for Scientists" but was disappointed to discover that they no 
longer work. Although Alex says:

  "I think this is one of the major problems with ocaml - you can find very 
interesting projects or modules, but they mostly abandon, never made it ever 
as far as beta..."

his problems are due to the exact opposite: my code has bitrotted slightly 
because the libraries it uses continue to be actively developed complete with 
breaking changes in order to improve APIs.

I shall go through all of the examples on our site and bring them up to date 
with respect to the latest libraries ASAP:

  http://www.ffconsultancy.com/products/ocaml_for_scientists/complete/?ol

However, I would like to stress that these are trivial changes. For 
example, my random matrix eigenvalue demo required only three tiny changes 
to bring it up to date with respect to the latest Lacaml library. 
Specifically, this:

  open Lacaml.S
  ...
  let m = Mat.of_array m in
  ignore (geev m);

becomes:

  let m = Lacaml.Mat4_S.of_array m in
  ignore (Lacaml.Impl.S.geev m);

The "n"th-nearest neighbour, travelling salesman and discrete wavelet 
transform examples all remain exactly the same. The only significant changes 
appear in the maximum entropy method example but Christophe Troestler has 
been kind enough to revamp the entire example as a demonstration of his newer 
and better bindings to FFTW3. You can get them with:

$ cvs -d:pserver:anonymous@ocaml-fftw.cvs.sourceforge.net:/cvsroot/ocaml-fftw 
login
$ 
cvs -z3 -d:pserver:anonymous@ocaml-fftw.cvs.sourceforge.net:/cvsroot/ocaml-fftw 
co -P fftw3

and look at "fftw3/examples/mem.ml" for the new MEM demo.

Perhaps members of the community would like to comment on some of Alex's other 
points, such as the lack of graph plotters for OCaml? IIRC, people have done 
substantial work on this in the past.

Depending how Jason Hickey's forthcoming OCaml book affects sales of "OCaml 
for Scientists", I may well write a second volume covering parallelism, GUI 
programming and graphing/charting using OCaml.

Although we are working heavily on F# now, there is no question in my mind 
that OCaml remains one of the most valuable tools for scientific computing 
under Linux.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re : [Caml-list] Not Rocket Science

[Adrien]

There are working binding to gnuplot in fact :
  http://sourceforge.net/projects/ocaml-gnuplot/

And there is also plplot and another one which name I can't remember.

As a side note, I recently used gnuplot but not with these bindings :
a very easy way to create plots with gnuplot is to write the plot
coordinates to a file (in human-readable format) and then run gnuplot
with the file as argument. That's as easy as :
  let log_c=open_out_bin "./results/pour_gnuplot.txt" in
  Printf.fprintf log_c "%d %f\n" !i !mistake
  (* this is an excerpt from an actual code *)
Then it is possible to have gnuplot create a image with three commands
I unfortunately can't remember properly (you just had to set the ouput
file, format and last issue "replot").

Last you can also use CamlImages.


As for the lack of documentation for modules, I had myself troubles
until I got the .mli thing. Now, after only a few months of ocaml, mli
files are usually all I need. This way, I had alsa, ao, mad or
xml-light working (just to name a few). However it took me some time,
probably because I simply wasn't aware of how much information they
carried and did not read them. Maybe Alexander Mikhalev was in the
same situation.


 ---

Adrien Nader

documentation (Re: Re : [Caml-list] Not Rocket Science)

[Oliver Bandel]

Zitat von Adrien <camaradetux@gmail.com>:

> There are working binding to gnuplot in fact :
>   http://sourceforge.net/projects/ocaml-gnuplot/
>
> And there is also plplot and another one which name I can't remember.
>
> As a side note, I recently used gnuplot but not with these bindings :
> a very easy way to create plots with gnuplot is to write the plot
> coordinates to a file (in human-readable format) and then run gnuplot
> with the file as argument. That's as easy as :
>   let log_c=open_out_bin "./results/pour_gnuplot.txt" in
>   Printf.fprintf log_c "%d %f\n" !i !mistake
>   (* this is an excerpt from an actual code *)
[...]

Using gnuplot is easiest to start with,
but when it comes to more sophisticated needs,
you soon will be stopped.

plplot is more powerful here, so this is nice even
for complex things (e.g. 3D-stuff with text also
rotated in 3D). But plplot's documentation is noc ecomplete,
and IMHO the usage of only 2D-arrays for 3D-data seems to be
not the best design decision. So the API looks not that good.
The documentation is big, but some necessary things are
not explained. And the examples in use use functions,
that are not explained in the documentation.

So, one has to do reverse engineering, isnetad of straightforwad
using the docs and start to code.

But this is a common problem in nearly all programming stuff,
open or closed source, applications or libraries...

IMHO the biggest necessity is better documentation.
This also gholds for a lot of OCaml-libraries, like
Camlimages and others.

It's fine to have the documentation showing all
types and values.
It's even better to explain, what modules can plugged in in which other
modules, meaning here: which types of the modules in use fit together.

yes, one can find out that by reading all docs and
re-organizing the stuff. A documentation IMHO should help the reader
here.

A documentation can reflect the possible plug-in's.
I'm not a monads-specialits, but as far as I have grasped
the concept (on the surface I think), it is this way,
how also a documentation could be done:

   Plug A in into B or C and it will work this way: ...
   Plug in C in F or Z, and it will work in this way....
   Plug in F in G and it will work like ...
   Plug in C into U or W and it will work also: it will do...


   So, you can Plug in A into C, and C into U or W.

And this can be shown as a graphic.
I have heard, computers in the year 2008 can use text as well
as graphics... ;-)

This would enhance readability and adaption of new things.

But it's also possible to only show the interfaces...
...when there are many module with types that can be used
in many ways, the reader needs more time to get an overview.

So, only some hints on how to make things more clear.

The above mentioned is meant in gerenal,
but I had tried to use CamlImages twice,
and there was a while between both trials, and
I ended up now in using jpeglib with C. ;-(
(But I already has used jpeglib a while ago,
 so this compoarision is a littlebit unfair ;-))


Ciao,
  Oliver

Re: [Caml-list] Not Rocket Science

[Richard Jones]

On Sun, Mar 02, 2008 at 10:41:54AM +0000, Jon Harrop wrote:
> I stumbled upon the following blog post by Alexander Mikhalev:
> 
>   "Why ocaml and haskell is not for scientists" -
> http://alexandermikhalev.blogspot.com/2008/01/why-ocaml-and-haskell-is-not-for.html

Sounds to me like he wants CPAN for OCaml, and indeed members of the
OCaml community are working on this right now.  The rest of it was
mostly an incoherent rant.  Hmmm.  Not sure how seriously I take a
blog with just one entry.

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] Not Rocket Science

[Jon Harrop]

On Sunday 02 March 2008 11:46:06 you wrote:
> As for the lack of documentation for modules, I had myself troubles
> until I got the .mli thing. Now, after only a few months of ocaml, mli
> files are usually all I need. This way, I had alsa, ao, mad or
> xml-light working (just to name a few). However it took me some time,
> probably because I simply wasn't aware of how much information they
> carried and did not read them. Maybe Alexander Mikhalev was in the
> same situation.

Well, he had read my book and chapter 2 details the use of the excellent 
ocamlbrowser tools for quickly and easily perusing OCaml APIs. All you need 
to do for Lacaml, for example, is add the "lacaml" directory to 
ocamlbrowser's search path and you can explore the Lacaml API within the 
comfort of a GUI application.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] Not Rocket Science

[Markus Mottl]

On Sun, Mar 2, 2008 at 5:41 AM, Jon Harrop <jon@ffconsultancy.com> wrote:
>  However, I would like to stress that these are trivial changes. For
>  example, my random matrix eigenvalue demo required only three tiny changes
>  to bring it up to date with respect to the latest Lacaml library.
>  Specifically, this:
>
>   open Lacaml.S
>   ...
>   let m = Mat.of_array m in
>   ignore (geev m);
>
>  becomes:
>
>   let m = Lacaml.Mat4_S.of_array m in
>   ignore (Lacaml.Impl.S.geev m);

The idiomatic way of implementing this now would be to open the
library as follows:

  open Lacaml.Impl.S

Then you can refer to the matrix module as "Mat" as usual, and you can
call all Lapack/Blas functions directly (also as usual).  The reason
for this change was the need to pack all Lacaml modules into their own
namespace.  At the time when Lacaml started out there was no packing
feature for libraries.  This change was reflected in the README.

Note that just by changing "S" to "D" when opening the library, you
can automatically switch your code from single to double precision
without having to change anything else.

Regards,
Markus

-- 
Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com

Re: documentation (Re: Re : [Caml-list] Not Rocket Science)

[Oliver Bandel]

Zitat von Oliver Bandel <oliver@first.in-berlin.de>:
[...]
> IMHO the biggest necessity is better documentation.
> This also holds for a lot of OCaml-libraries, like
> Camlimages and others.

I didn't meant the standard lib...
(...but possibly, because I now know how to use them?)



>
> It's fine to have the documentation showing all
> types and values.
> It's even better to explain, what modules can plugged in in which
> other
> modules, meaning here: which types of the modules in use fit
> together.

With ocamldoc for example it is possible to show
the relations of the modules of a program, and to
show which module uses which other module.
(graphviz-output). This is a quite good idea.

To have such a thing for the way,
modules should/can be plugged together,
determined by the custom types that are provided by the modules,
would enhance readability and understanding of a documentation a lot!

I'm not sure if this should be an additional function for ocamldoc;
possibly one also could create dummy-applications that use modules
in a way, so that plug-in possibilities can be shown with ocamldoc,
when using the graphviz-option. But this are
indirections/detours/workarounds.

Possibly an new, added functionality of ocamldoc or another
application could be used here.

Or is ocamlbuild able to create such stuff?
As I so far didn't used it, maybe someone knows
if it can be used for such documentation-enhancements?


Ciao,
   Oliver