From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: ** X-Spam-Status: No, score=2.3 required=5.0 tests=HTML_10_20,HTML_MESSAGE, SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id C0B23BC6B for ; Thu, 8 Mar 2007 02:49:59 +0100 (CET) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l281nwma029773 for ; Thu, 8 Mar 2007 02:49:59 +0100 Received: by nf-out-0910.google.com with SMTP id m19so407327nfc for ; Wed, 07 Mar 2007 17:49:58 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=IvcoRmzGxaUhu0zRmL+GXDpty9tPov0p/3gI68kQeut+5P+jgUnTWbJgFxhhJH5BCf6pBWxqchHpDlQldE7FFnse1hTsgo6rSD8XCTGPIFOIbHX/RkvRjVeheon/f+/6d25qChW6JU6Buqxv/CEyYW+F23HkmbTxUw79bHShqhk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=mgVwpxFBei64+rwoC7JBvNrL1/HcfrOx/wrsL15RmWqXqnnqlCXP12SOb07T/fIqNp0VbZZCWT4fjaV1QU95x33Yse6K49NBJL47vZYT3689x8pF8y3joNn86J4cM0YFC4sIqqDJqMZusblhXvK4TdRIiPbRAL3qAgVM1W0dUtA= Received: by 10.114.152.17 with SMTP id z17mr2443337wad.1173318597399; Wed, 07 Mar 2007 17:49:57 -0800 (PST) Received: by 10.114.168.3 with HTTP; Wed, 7 Mar 2007 17:49:57 -0800 (PST) Message-ID: Date: Wed, 7 Mar 2007 20:49:57 -0500 From: "Jim Miller" To: "Jon Harrop" Subject: Re: [Caml-list] Interactive technical computing Cc: caml-list@inria.fr In-Reply-To: <200703080113.22721.jon@ffconsultancy.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_214343_32464513.1173318597357" References: <200703080113.22721.jon@ffconsultancy.com> X-j-chkmail-Score: MSGID : 45EF6BC6.004 on concorde : j-chkmail score : X : 0/20 1 0.000 -> 1 X-Miltered: at concorde with ID 45EF6BC6.004 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; idl:01 ocaml:01 gnuplot:01 ocaml:01 compilation:01 regexps:01 spawned:01 low-level:01 high-level:01 spawned:01 dlls:01 overloading:01 vectors:01 matrices:01 annotation:01 ------=_Part_214343_32464513.1173318597357 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I think that this would be a potentially fantastic application! As a physicist I am frequently faced with the option of using an interactive tool that supports graphics (PV-WAVE, IDL, R, and Matlab/Octave are very popular) but is VERY slow or doing things in a fast but tedious language (C/C++ are currently the rage with a few individuals that still do Fortran 9X). Having an OCaml based language that combines a top level command line loop that allows me to interactive explore data and develop scripts but that allows me to compile those into something fast could be a very, very useful tool. My particular domains are atmospheric photochemistry as well as satellite mission planning and imagery exploitation. We tend to do a LOT less with 3D visualizations and much more with traditional line, contour, and scatter plots. We also do a lot of false color imagery. The closest that I have come to this is a quick module that allows me to spawn a gnuplot program and pass command strings, via a pipe. A few functions to ensure that data is formatted properly and I have something that's manageable. I'd be interested in conspiring/planning on something in this space. It would also be useful to see if there's a useful way to bridge this with R, which is my current favorite language for doing statistical data analysis and plot generation but it still suffers from the problems of speed. On 3/7/07, Jon Harrop wrote: > > > Being a user of both OCaml and Mathematica, playing with the new F# > language > from Microsoft and watching tutorial videos about VPython: > > http://showmedo.com/videos/series?name=pythonThompsonVPythonSeries > > has given me a lot of inspiration about interactive technical computing > environments. This class of applications is hugely useful for working > scientists and engineers because it lets you slice and dice your data in > interesting ways whilst also giving you visual throwback and even letting > you > do some fancy visualisations. > > For example, I'm in the process of updating my ray tracer language > comparison: > > http://www.ffconsultancy.com/languages/ray_tracer/index.html > > and I'm using a mix of OCaml (to fire off compilation and execution > commands) > and Mathematica (to dissect the results, compute verbosity using regexps > and > plot graphs): > > http://www.ffconsultancy.com/tmp/mathematica.png > > Mathematica's equivalent of the OCaml top-level is called a notebook. It > provides expression input and result output, just like OCaml, but > integrates > graphics, adds typesetting and lots of mathematical functions. However, it > is > widely used for more general purpose programming despite being very slow. > > Using F# from Visual Studio 2005 provides some of this functionality. The > following screenshots illustrate 2D and 3D graphics spawned from an F# > interactive session using a little of my own code and > DirectX/ComponentsXtra: > > http://www.ffconsultancy.com/tmp/fs_xygraph.png > http://www.ffconsultancy.com/tmp/fs_3dplot.png > > For all non-trivials examples in F# it is necessary to spawn a separate > thread > to handle the GUI of the visualization, or the GUI will hang when the > top-level is doing an intensive computation. > > I think F# has a great future because of its ability to spawn > visualizations > from a running interactive session. Expensive commercial offerings like > Matlab and Mathematica are ok when you're doing something they have > built-in > (e.g. a Fourier transform) but when you're problem is not trivially > decomposed into their built-in operators (e.g. a wavelet transform), F# > and > OCaml are typically 2-5x faster, and when you must resort to more general > purpose programming F# and OCaml are often 100x faster. > > However, there is a lot of work to be done in getting competitive charting > and > visualization tools into F# and I'm thinking that OCaml could benefit from > a > joint venture here. Low-level routines would target DirectX in F# and > OpenGL > in OCaml but high-level routines could be language and platform agnostic, > handling a scene graph that is essentially a typed version of > Mathematica's > to provide much faster graphics and even interactive visualisation > (Mathematica is software rendered and not interactive!). > > This raises several questions: > > . What OCaml programs currently allow OpenGL-based visualizations to be > spawned from the top-level? > > . Has anyone tried to write an IDE that mixes OCaml code with graphics? > > . Would anyone here be interested in a low-cost cross-platform technical > computing environment based upon the OCaml and F# languages? > > Obviously I'm interested in this from a commercial perspective. That looks > easy for F# but not so easy for OCaml. Compiled OCaml+OpenGL code is not > as > portable (between machines) as F#+DirectX. Also, I can sell F# DLLs and > even > make the library available to other .NET languages (albeit with a > significantly less productive API). > > 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. Even if you have to add the odd type annotation. So I'd love > to > see a compatible implementation of overloading introduced into OCaml. > > I'd like to hear everyone's opinions on this as, it seems to me, we're > sitting > on the foundations of a great technical computing system. > > -- > Dr Jon D Harrop, Flying Frog Consultancy Ltd. > OCaml for Scientists > http://www.ffconsultancy.com/products/ocaml_for_scientists > > _______________________________________________ > 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 > ------=_Part_214343_32464513.1173318597357 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think that this would be a potentially fantastic application!  As a physicist I am frequently faced with the option of using an interactive tool that supports graphics (PV-WAVE, IDL, R, and Matlab/Octave are very popular) but is VERY slow or doing things in a fast but tedious language (C/C++ are currently the rage with a few individuals that still do Fortran 9X).

Having an OCaml based language that combines a top level command line loop that allows me to interactive explore data and develop scripts but that allows me to compile those into something fast could be a very, very useful tool.  My particular domains are atmospheric photochemistry as well as satellite mission planning and imagery exploitation.  We tend to do a LOT less with 3D visualizations and much more with traditional line, contour, and scatter plots.  We also do a lot of false color imagery.

The closest that I have come to this is a quick module that allows me to spawn a gnuplot program and pass command strings, via a pipe.  A few functions to ensure that data is formatted properly and I have something that's manageable.

I'd be interested in conspiring/planning on something in this space.  It would also be useful to see if there's a useful way to bridge this with R, which is my current favorite language for doing statistical data analysis and plot generation but it still suffers from the problems of speed.

On 3/7/07, Jon Harrop <jon@ffconsultancy.com> wrote:

Being a user of both OCaml and Mathematica, playing with the new F# language
from Microsoft and watching tutorial videos about VPython:

   http://showmedo.com/videos/series?name=pythonThompsonVPythonSeries

has given me a lot of inspiration about interactive technical computing
environments. This class of applications is hugely useful for working
scientists and engineers because it lets you slice and dice your data in
interesting ways whilst also giving you visual throwback and even letting you
do some fancy visualisations.

For example, I'm in the process of updating my ray tracer language comparison:

  http://www.ffconsultancy.com/languages/ray_tracer/index.html

and I'm using a mix of OCaml (to fire off compilation and execution commands)
and Mathematica (to dissect the results, compute verbosity using regexps and
plot graphs):

  http://www.ffconsultancy.com/tmp/mathematica.png

Mathematica's equivalent of the OCaml top-level is called a notebook. It
provides expression input and result output, just like OCaml, but integrates
graphics, adds typesetting and lots of mathematical functions. However, it is
widely used for more general purpose programming despite being very slow.

Using F# from Visual Studio 2005 provides some of this functionality. The
following screenshots illustrate 2D and 3D graphics spawned from an F#
interactive session using a little of my own code and DirectX/ComponentsXtra:

  http://www.ffconsultancy.com/tmp/fs_xygraph.png
   http://www.ffconsultancy.com/tmp/fs_3dplot.png

For all non-trivials examples in F# it is necessary to spawn a separate thread
to handle the GUI of the visualization, or the GUI will hang when the
top-level is doing an intensive computation.

I think F# has a great future because of its ability to spawn visualizations
from a running interactive session. Expensive commercial offerings like
Matlab and Mathematica are ok when you're doing something they have built-in
(e.g. a Fourier transform) but when you're problem is not trivially
decomposed into their built-in operators (e.g. a wavelet transform), F# and
OCaml are typically 2-5x faster, and when you must resort to more general
purpose programming F# and OCaml are often 100x faster.

However, there is a lot of work to be done in getting competitive charting and
visualization tools into F# and I'm thinking that OCaml could benefit from a
joint venture here. Low-level routines would target DirectX in F# and OpenGL
in OCaml but high-level routines could be language and platform agnostic,
handling a scene graph that is essentially a typed version of Mathematica's
to provide much faster graphics and even interactive visualisation
(Mathematica is software rendered and not interactive!).

This raises several questions:

. What OCaml programs currently allow OpenGL-based visualizations to be
spawned from the top-level?

. Has anyone tried to write an IDE that mixes OCaml code with graphics?

. Would anyone here be interested in a low-cost cross-platform technical
computing environment based upon the OCaml and F# languages?

Obviously I'm interested in this from a commercial perspective. That looks
easy for F# but not so easy for OCaml. Compiled OCaml+OpenGL code is not as
portable (between machines) as F#+DirectX. Also, I can sell F# DLLs and even
make the library available to other .NET languages (albeit with a
significantly less productive API).

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. Even if you have to add the odd type annotation. So I'd love to
see a compatible implementation of overloading introduced into OCaml.

I'd like to hear everyone's opinions on this as, it seems to me, we're sitting
on the foundations of a great technical computing system.

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

_______________________________________________
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

------=_Part_214343_32464513.1173318597357--