Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
OCaml App (NML) Announce
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: David McClain <dmcclain@a...>
Subject: Re: scientific computing with ocaml, gsl api
It would appear that any external library developed in C would be a huge
risk to code safety. NML was coded to the greatest possible degree in OCaml
for exactly this reason. It (OCaml, and hence NML) has a superb and robust
GC, and runtimes errors cannot crash the apps. Instead, if an NML routine is
misused, it simply gives an error message at runtime, along with a traceback
of most recent call paths, identify source file and line from which the
error propagated.

I am personally leary of C code, even though I have more than 20 years
experience with it -- perhaps because I have so much experience with it! In
every recent case where a program exhibited anomalous behavior and needed
debugging I could trace it back to the use of C/C++. These are generally
off-by-one boundary condition errors, but sometimes logic errors that have
been obfuscated by the lack of clean syntax such as offered by OCaml. I
don't generally have dangling pointer problems in my life, but many others
do. I personally prefer to have a robust and fast GC running so I don't have
to become a memory accountant.

Hence, if the "gsl" library were to be recast entirely (or almost so) in
OCaml I would be much more interested in using it. As it stands in C, I
would be quite distrustful of it.

- DM

----- Original Message -----
From: Julian Assange <>
To: David McClain <>
Cc: <>; <>
Sent: Tuesday, March 28, 2000 11:00 PM
Subject: scientific computing with ocaml, gsl api

> "David McClain" <> writes:
> > Dear OCaml Enthusiasts,
> >
> > It has been stewing for more than a year now, a continuing work in
> > but it is high time that I release a matured copy of the code and
sources to
> > the world. NML (Not ML, Numeric Modeling Language, Numeric ML, Nearly
> > ...) is an interactive, dynamically typed, tail pure, compiled (to
> > code closures) functional language, whose syntax closely follows that of
> > OCaml, but where all math operations are overloaded and vectorized on
> > and complex data in the form of lists, vectors, multidimensional arrays,
> > tuples, etc.
> This looks very nice david! Is it possible to use the vectorised, array
> within ocaml? i.e I'm a little leary of using NML for mid-large
applications due
> to the lack of type checking, but it does seem to be an excellent language
> scientific interrogation.
> Have you looked at the GNU scientific library?
> This is a wonderfully eclectic scientific library in C, with strong
> control over float properties. An ocaml or MNL binding would be a
> killer app.
>  > Are there any plans to support euclidian vector algebra in n
>  > dimensions? Preferably with user-defined physical field properties?
>  >
>  > Specifically I want to be able to do things like define two vectors,
>  > v_1, and v_2, have v_1 radiate a force decreasing at 1/distance^2, and
>  > calculate the the force vector across all of v_2. This is more complex
>  > than simple point sources, but there doesn't even seem to be support
>  > for those. It could be argued that a two body case is so trivial it
>  > doesn't need supporting, which is probably true, but n body cases and
>  > non point sources are hard work and useful in many (even non-physics)
>  > applications. i.e the v_1, v2 example I mentioned above forms part of
>  > an optimisation solution I have for laying out 2d chemical labels
>  > (part-of-molecule number, atomic weight, charge, etc) over a 3d
>  > polynucleartide in such a way as to avoid the labels writing accross
>  > each other.
>  >
>  > Cheers,
>  > Julian