From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA18474 for caml-red; Mon, 25 Dec 2000 22:08:26 +0100 (MET)
Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA07020 for <caml-list@pauillac.inria.fr>; Fri, 22 Dec 2000 19:34:52 +0100 (MET)
Received: from sunshine.math.utah.edu (sunshine.math.utah.edu [128.110.198.2])
	by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id eBMIYo516006
	for <caml-list@inria.fr>; Fri, 22 Dec 2000 19:34:51 +0100 (MET)
Received: from suntan.math.utah.edu (suntan.math.utah.edu [155.99.144.26])
	by sunshine.math.utah.edu (8.9.3/8.9.3) with ESMTP id LAA27945;
	Fri, 22 Dec 2000 11:34:48 -0700 (MST)
Received: (from hohn@localhost)
	by suntan.math.utah.edu (8.9.3/8.9.3) id LAA24027;
	Fri, 22 Dec 2000 11:34:47 -0700 (MST)
Date: Fri, 22 Dec 2000 11:34:47 -0700 (MST)
Message-Id: <200012221834.LAA24027@suntan.math.utah.edu>
X-Authentication-Warning: suntan.math.utah.edu: hohn set sender to hohn@suntan.math.utah.edu using -f
From: Michael Hohn <hohn@math.utah.edu>
To: semenova@snob.spb.ru
CC: caml-list@inria.fr
In-reply-to: <00122200235700.00634@snob.spb.ru> (message from Semenova Natalya
	Nickolaevna on Thu, 21 Dec 2000 23:39:37 +0300)
Subject: Re: Is Caml a suitable tool for complicated mathematical methods.
References:  <00122200235700.00634@snob.spb.ru>
Sender: weis@pauillac.inria.fr


   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"
}