Version française
Home     About     Download     Resources     Contact us    
Browse thread
Interactive technical computing
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Christophe TROESTLER <Christophe.Troestler+ocaml@u...>
Subject: Re: [Caml-list] Interactive technical computing
Hi,

I certainly am interested in such a project (even to contribute though
my time is limited).

> On Thu, 8 Mar 2007, Jon Harrop <jon@ffconsultancy.com> wrote:
> > 
> > I think F# has a great future because of its ability to spawn
> > visualizations from a running interactive session.  [...]

I have written a Gnuplot module that allows that.  Here is the
compulsory screenshot :)

  ftp://ftp.umh.ac.be/pub/ftp_san/Ocaml-gnuplot.png

Code :

  # load "gnuplot.cma";;
  # module G = Gnuplot.Array;;
  # let g = G.init G.X;;
  # G.box g;;
  # G.pen g 1;;
  # G.fx g sin (-1.) 20.;;

It definitely needs some further work but I do not have much time for
that now.  Also, I need to be able to plot data defined on triangular
meshes (and non square domains) and Gnuplot does not allow that so I
am looking for a solution viable for a longer term.

Maybe a wrapper for VTK (http://www.vtk.org/) could be a good start --
and trivially solves the portability issues.

> > Obviously I'm interested in this from a commercial
> > perspective. That looks easy for F# but not so easy for OCaml.
> > [...]
On Thu, 08 Mar 2007, Gerd Stolpmann <info@gerd-stolpmann.de> wrote:
> 
> - Make the product open-source (this is a door-opener!)

Unless it is open source, I would not use such a product.  Having it
open source is the only waranty for long term security.  I would not
develop codes that cannot run 5 years later because, say, you
unfortunately went to bankruptcy... or you became crazy and ask 10
times more money... or...

> > Finally, I'd like to note that operator overloading is probably
> > the single biggest difference between my F# and OCaml code. The
> > ability to apply + and - to many types, particularly vectors and
> > matrices, makes this kind of work so much easier.

That would not completely remove the problem of adding some operators
but I was thinking of a possibly generic solution using Camlp4:
writing [X.(a + b)] where [X] is a module would become [X.add a b].
Now for matrices, one still needs + (for matrix addition), * (for
matrix multiplication) and, say, .* (for scalar product).  So to be
generic, one needs to be able to specify a set of operators (with
precedences) and a way to transform an AST of that mini language into
Caml code (that would possibly allow some optimisations, analysing the
expression at compile time to reduce de number of intermediate
matrices allocated).  A slicing notation also needs to be developed,
say [a.{1, 2:3:7}], as well as a good ASCII pretty printer for
matrices (they must be bigarrays to be able to use interesting
libraries).

Cheers,
ChriS