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 XAA02086 for caml-redistribution@pauillac.inria.fr; Sun, 2 Apr 2000 23:23:37 +0200 (MET DST) Resent-Message-Id: <200004022123.XAA02086@pauillac.inria.fr> 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 WAA18744 for ; Wed, 29 Mar 2000 22:08:30 +0200 (MET DST) Received: from cepheus.azstarnet.com (cepheus.azstarnet.com [169.197.56.195]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id WAA20380 for ; Wed, 29 Mar 2000 22:08:29 +0200 (MET DST) Received: from vega (dialup001ip105.tus.azstarnet.com [169.197.12.105]) by cepheus.azstarnet.com (8.9.3+blt.Beta0/8.9.3) with SMTP id NAA02542; Wed, 29 Mar 2000 13:08:17 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ Message-ID: <000a01bf99ba$8c3ae520$250148bf@vega> From: "David McClain" To: "Julian Assange" Cc: , References: <000501bf95d4$7f544de0$250148bf@vega> Subject: Re: scientific computing with ocaml, gsl api Date: Wed, 29 Mar 2000 13:08:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Resent-From: weis@pauillac.inria.fr Resent-Date: Sun, 2 Apr 2000 23:23:37 +0200 Resent-To: caml-redistribution@pauillac.inria.fr 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 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 >