Interactive technical computing
[
Home
]
[ Index:
by date

by threads
]
[ Message by date: previous  next ] [ Message in thread: previous  next ] [ Thread: previous  next ]
[ Message by date: previous  next ] [ Message in thread: previous  next ] [ Thread: previous  next ]
Date:  20070308 (14:24) 
From:  Christophe TROESTLER <Christophe.Troestler+ocaml@u...> 
Subject:  Re: [Camllist] 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/Ocamlgnuplot.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@gerdstolpmann.de> wrote: > >  Make the product opensource (this is a dooropener!) 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