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 TAA02893 for caml-redistribution@pauillac.inria.fr; Wed, 29 Mar 2000 19:20:40 +0200 (MET DST) Resent-Message-Id: <200003291720.TAA02893@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 JAA19674 for ; Wed, 29 Mar 2000 09:14:28 +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 JAA27703 for ; Wed, 29 Mar 2000 09:14:27 +0200 (MET DST) Received: from vega (dialup001ip466.tus.azstarnet.com [169.197.13.210]) by cepheus.azstarnet.com (8.9.3+blt.Beta0/8.9.3) with SMTP id AAA12691; Wed, 29 Mar 2000 00:14:15 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ Message-ID: <002301bf994e$6ae2a3c0$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 00:13:47 -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: Wed, 29 Mar 2000 19:20:40 +0200 Resent-To: caml-redistribution@pauillac.inria.fr Julian, I'm not quite sure what you mean by Euclidean N-dimensional algebra, but NML does already support inner and outer products of N-dimensional objects. There are also Matrix routines for SVD, Cholesky decomposition, and LU decomposition, inversion, and determinants, etc... In fact one of the things I do quite frequently is a DFT demodulation of image stacks obtained with a chopped sensor. Hence to multiply and sum the image planes with a twiddle vector I simply do: images <*> twiddles and voila, the result is a single image that represents the sum of individual weighted images. The "images" vector above is a 3-dimensional stack of 2-D image planes, while the "twiddles" is a simple vector of scalar (complex) weights. The "<*>" is shorthand for my inner-product operator. I am sure that you will easily represent your force problem in the vectorized domain of NML! - 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 >