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 <proff@iq.org>
To: David McClain <dmcclain@azstarnet.com>
Cc: <caml-list@inria.fr>; <proff@iq.org>
Sent: Tuesday, March 28, 2000 11:00 PM
Subject: scientific computing with ocaml, gsl api
> "David McClain" <dmcclain@azstarnet.com> writes:
>
> > Dear OCaml Enthusiasts,
> >
> > It has been stewing for more than a year now, a continuing work in
progress,
> > 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
ML,
> > ...) is an interactive, dynamically typed, tail pure, compiled (to
native
> > code closures) functional language, whose syntax closely follows that of
> > OCaml, but where all math operations are overloaded and vectorized on
real
> > 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
support
> 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
for
> scientific interrogation.
>
> Have you looked at the GNU scientific library?
>
> http://sourceware.cygnus.com/gsl
>
> 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
>
This archive was generated by hypermail 2b29 : Sun Apr 02 2000 - 23:31:32 MET DST