From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.6.10/8.6.6) id TAA04347 for caml-redistribution; Wed, 18 Oct 1995 19:09:41 +0100 Received: (from weis@localhost) by pauillac.inria.fr (8.6.10/8.6.6) id TAA04268; Wed, 18 Oct 1995 19:05:26 +0100 From: Pierre Weis Message-Id: <199510181805.TAA04268@pauillac.inria.fr> Subject: Re: caml (special) light and numerics To: ohl@crunch.ikp.physik.th-darmstadt.de (Thorsten Ohl) Date: Wed, 18 Oct 1995 19:05:26 +0100 (MET) Cc: caml-list@pauillac.inria.fr In-Reply-To: <9510181541.AA23639@crunch> from "Thorsten Ohl" at Oct 18, 95 04:41:32 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: weis > How can I get around Array.new in > > val f : float array -> float array > > let f x = > let n = Array.length x in > let y = Array.new n 0.0 in > for i = 0 to n do > for j = 0 to n do > y.(i) <- y.(i) +. a.(i).(j) *. x.(j) > done > done > > The problem is that I cannot modify `x' in place (even if I know that > I won't need it later). You're right, you must allocate it (but don't forget to return it at the end of the loop). > The solution > > val g : float array -> float array -> unit > > let f x y = > let n = Array.length x in > for i = 0 to n do > for j = 0 to n do > y.(i) <- y.(i) +. a.(i).(j) *. x.(j) > done > done > > comes to mind, but it forces me to think of the operation in terms of > side efects, not in a functional way. That's true. Write it that way only if this computation is a side-effect, that is if the y parameter is in fact an accumulator. > No doubt about that, but I'm trying to figure out if it is _likely_ > that also production level code can be produced. Cslopt is certainly > an example, but from a very different field. I'm thinking about > implementing a non-trivial system and I need _some_ idea if it has a > chance to fly. > OTOH, a factor of ten can be painful if it means that you have to > wait a week, instead of a night. Well it's very difficult to answer. I think that it is worth trying. Especially because Caml is easy to interface to C: if you get a bottleneck somewhere, and if the corresponding C code is much more efficient than the Caml code, you may delegate this computation to C. On the other hand, the rest of your system may stay in Caml and be written in a clean and easy to maintain style. We got a similar architecture for the bignum arithmetic facility of Caml: the very low level layer of the arithmetic that performs in place computation is written in assembly code (or in C, depending on the hardware). Higher level layers of the arithmetic were written in Caml: for these parts, the algorithmic was not so well established and once more we found it comfortable to experiment in Caml. Pierre Weis ---------------------------------------------------------------------------- WWW Home Page: http://pauillac.inria.fr/~weis Projet Cristal INRIA, BP 105, F-78153 Le Chesnay Cedex (France) E-mail: Pierre.Weis@inria.fr Telephone: +33 1 39 63 55 98 Fax: +33 1 39 63 53 30 ----------------------------------------------------------------------------