From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id EAA04126; Tue, 5 Jun 2001 04:53:01 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 EAA04019 for ; Tue, 5 Jun 2001 04:53:00 +0200 (MET DST) Received: from shell5.ba.best.com (shell5.ba.best.com [206.184.139.136]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f552qxX19483 for ; Tue, 5 Jun 2001 04:52:59 +0200 (MET DST) Received: from localhost (bpr@localhost) by shell5.ba.best.com (8.9.3/8.9.2/best.sh) with ESMTP id TAA16705; Mon, 4 Jun 2001 19:52:55 -0700 (PDT) Date: Mon, 4 Jun 2001 19:52:55 -0700 (PDT) From: Brian Rogoff To: Tom _ cc: William Chesters , caml-list@inria.fr Subject: Re: [Caml-list] OCaml Speed for Block Convolutions In-Reply-To: <20010604221414.49620.qmail@web11906.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Mon, 4 Jun 2001, Tom _ wrote: > > E.g. > > > > let a = ref 0. in > > for i = 0 to n-1 do > > a := !a +. Array.unsafe_get xs i > > done > > Incidentally, rather than trying to come up > with other workaround for imperative variables, > maybe it would be better to just make the > straightforward functional implementation fast: > > let loop i total = > if i=n then total else > loop (i+1) (total + Array.unsafe_get xs i) > in loop 0 0.0 > > In fact, in a compiler that already has TRO > and type inference, shouldn't this be entirely > equivalent to an imperative loop? Yes, but I think the general problem that William Chesters alludes to (the overhead of polymorphic variables) is an interesting one to solve regardless. Coming back to the subject of this thread, in an ideal world, there wouldn't be a need to distinguish between Bigarray and Array, you'd just use polymorphic arrays and the compiler would be smart enough to always get unboxed and tag free element representations. Supposedly Stalin comes close (I've only played with it on *very* small programs) so maybe one day we'll get something similar. And maybe David McClain wouldn't have to write his inner loops in C or Fortran. What a wonderful world that would be... > Another approach would be to adopt a "functional" > loop syntax as found in languages like SISAL. Or SAC. But OCaml arrays (and strings) aren't functional, and the only Clean and efficient way I know to deal with that is uniqueness type information. Functional arrays (trees or version arrays) are not efficient enough to replace imperative arrays when you have single threaded usage; definitely not the right data structure for signal processing or numerical linear algebra. OTOH (changing the subject) it might be nice to have built in version arrays and functional strings for other reasons. -- Brian ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr