Re: Is Caml a suitable tool for complicated mathematical methods.

Re: Is Caml a suitable tool for complicated mathematical methods.

[Daniel Ortmann]

As Markus recommended on comp.lang.functional, the following is worthwhile
reading:

http://perl.plover.com/yak/typing/typing.html

While it was addressed to a "perl" audience, it discusses static typing issues
in Pascal and ML-like languages (and others).  Definately a *must* read.

--
Daniel Ortmann, IBM Circuit Technology, Rochester, MN 55901-7829
ortmann@us.ibm.com / internal 8.553.6795 / external 507.253.6795
ortmann@isl.net home 507.288.7732

"The answers are so simple, and we all know where to look,
but it's easier just to avoid the question." -- Kansas




Semenova Natalya Nickolaevna <semenova@snob.spb.ru>@inria.fr on 12/21/2000
02:39:37 PM

Sent by:  Pierre.Weis@inria.fr


To:   caml-list@inria.fr
cc:
Subject:  Is Caml a suitable tool for complicated mathematical methods.



Hi,

We are going to rewrite a large bundle of Fortran-3 (!!!) sources to some
"better" language. Sources are the solution of the system of differential
equations in partial derivatives by normal finite differencing methods.

Two candidats are voted: Pascal and Ocaml. Is Caml convenient tool for such
tasks?

 --
----------------
Semyonova Natalya Nickolaevna
----------------

Is Caml a suitable tool for complicated mathematical methods.

[Semenova Natalya Nickolaevna]

Hi,

We are going to rewrite a large bundle of Fortran-3 (!!!) sources to some
"better" language. Sources are the solution of the system of differential
equations in partial derivatives by normal finite differencing methods. 

Two candidats are voted: Pascal and Ocaml. Is Caml convenient tool for such
tasks?

 -- 
----------------
Semyonova Natalya Nickolaevna
----------------

Re: Is Caml a suitable tool for complicated mathematical methods.

[Brian Rogoff]

On Thu, 21 Dec 2000, Semenova Natalya Nickolaevna wrote:
> Hi,
> 
> We are going to rewrite a large bundle of Fortran-3 (!!!) sources to some
> "better" language. Sources are the solution of the system of differential
> equations in partial derivatives by normal finite differencing methods. 

A walk down memory lane for me. What kind of PDEs are you going to be
solving? 

> Two candidats are voted: Pascal and Ocaml. Is Caml convenient tool for such
> tasks?

Well, you ask here, so I guess I'll give the expected answer: of course
Ocaml is the right tool for this! 

More seriously, which Pascal are you considering? One of the few annoyances 
I'd have with Ocaml is the lack of overloading of arithmetic ops, and
since Pascal doesn't allow it either (true for all Pascal's I know of,
including Oberon descendant Component Pascal) you're worse of there than
in Ocaml, where you may at least rebind the operators to whatever you
like best. If you must use a Pascal-like language you should use Ada
instead; GNAT is a magnificent piece of work. 

Assuming you make the right choice and go with Ocaml, take a look at the
new Bigarray library. I don't think the basic Array stuff is what you want 
for PDE solvers. You come to Ocaml at a good time, since the Bigarray
module was recently added and some floating point optimizations were also 
put in recently. Work on Gtk bindings is progressing so you'll be able to 
do nice graphics too. 

Welcome aboard!

-- Brian

Re: Is Caml a suitable tool for complicated mathematical methods.

[Michael Hohn]

   We are going to rewrite a large bundle of Fortran-3 (!!!) sources to some
   "better" language. Sources are the solution of the system of differential
   equations in partial derivatives by normal finite differencing methods. 

   Two candidats are voted: Pascal and Ocaml. Is Caml convenient tool for such
   tasks?

Definitely.  I finished an implementation of a linear elliptic pde
solver using sinc methods** last summer, and ocaml made this a 
*very* pleasant experience.  To me, the biggest advantages over most
other languages, especially Pascal, FORTRASH (no typo there) and C
are: 

o functional programming
  A programming style much better suited for numerical math than
  imperative ever was.  
  Closures alone reduce programming effort tremendously, and yield
  very clean code.  Just try translating the following piece to Pascal
  or C:

     let make_phi a b  =
     fun x -> (log ((x-. a)/. (b-. x)));;
     >> val make_phi : float -> float -> float -> float = <fun>
   
     let phis = [| make_phi 0.0 1.0; make_phi 2.1 3.2 |];;
     >> val phis : (float -> float) array = [|<fun>; <fun>|]
   
     phis.(0) 0.1;;
     >> - : float = -2.19722457734
   
     phis.(1) 3.1;;
     >> - : float = 2.30258509299
  The stuff following >> is the toplevel's output.


o interactive toplevel
  The ability to test individual functions without the lengthy 
  write-compile-run cycle is hard to do without.

o type inference
  As the small sample above shows, type declarations are not usually
  needed.  This means *much* shorter code when writing smaller
  functions. 

o data serialization
  The ability to produce *portable* binary data files from *arbitrary*
  data structures (as long as they contain no closures or objects)
  with a single function call is priceless.

  With this, I was able to run a large problem at the university on a
  Sun Ultrasparc with 2GB of memory, save the results, transfer the
  binary file, and work with that file at home using a Pentium II
  running Linux.  All by writing about 20 lines of extra code!

o defineable operators
  For example, ocaml does not have complex number support built-in.
  No problem.  After defining some basic complex functionality, the
  following works by defining the *: operator:
    # #load "cmplx.cmo";;
    # open Cmplx;;
    # (cx 1.0 1.0) *: (cx (-2.0) 1.1);;
    - : Cmplx.cmplx = {re=-3.1; im=-0.9}
    # zexp (cx 3.5 27.1);;
    - : Cmplx.cmplx = {re=-12.7877837182; im=30.5467796339}
	
There are many other advantages, too tedious to describe.  At least
the following are worth mentioning:
o garbage collection
o polymorphism
o strong static typing
o module support

I hope this very brief summary helps.

Happy programming,
    Michael


P.S. Is anybody interested in using/extending the complex number code?


** Based on many papers and the book
@Book{stenger,
  author =	 "Stenger, Frank",
  title =	  "Numerical Methods Based on Sinc and Analytic Functions",
  publisher =	 "Springer-Verlag",
  year =     "1993"
}

Re: Is Caml a suitable tool for complicated mathematical methods.

[Vitaly Lugovsky]

On Thu, 21 Dec 2000, Semenova Natalya Nickolaevna wrote:

> Hi,
> 
> We are going to rewrite a large bundle of Fortran-3 (!!!) sources to some
> "better" language. Sources are the solution of the system of differential
> equations in partial derivatives by normal finite differencing methods. 
> 
> Two candidats are voted: Pascal and Ocaml. Is Caml convenient tool for such
> tasks?

 OCaml is a good tool to automate this migration to any other language.
But the target language, IMHO, shall be Fortran-90, not ocaml or pascal.
Pascal is not situated for numerical tasks at all, it's a dead language,
and OCaml can be too slow for your task (not SO slow, but, of course,
slower then good old Fortran). If you really need a fast and modern
language for numerical computations, there is no better choice then latest
Fortran realizations. Think about it: automatic parallelism (on SMP),
VERY good optimizations, easy-to-proove syntax. btw, you can even use
ocaml to proove your Fortran code automatically.

--

   V.S.Lugovsky aka Mauhuur (http://ontil.ihep.su/~vsl) (UIN=45482254)