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 WAA23306; Wed, 28 Apr 2004 22:47:09 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA23284 for ; Wed, 28 Apr 2004 22:47:08 +0200 (MET DST) Received: from ptb-relay03.plus.net (ptb-relay03.plus.net [212.159.14.214]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i3SKl7YM028255 for ; Wed, 28 Apr 2004 22:47:07 +0200 Received: from [80.229.56.224] (helo=chetara) by ptb-relay03.plus.net with esmtp (Exim) id 1BIvxS-000Gtc-Bv for caml-list@inria.fr; Wed, 28 Apr 2004 20:47:06 +0000 From: Jon Harrop Organization: University of Cambridge To: caml-list Subject: Re: [Caml-list] Re: [ANN] The Missing Library Date: Wed, 28 Apr 2004 21:00:14 +0100 User-Agent: KMail/1.5.4 References: <927F2151-992E-11D8-AABC-000393942C76@ece.ucsb.edu> <1083172450.9537.1149.camel@pelican.wigram> In-Reply-To: <1083172450.9537.1149.camel@pelican.wigram> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200404282100.14617.jdh30@cam.ac.uk> X-Miltered: at concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 2004:99 euclidean:01 gcc:01 segfault:01 generalised:01 rank:99 rank:99 calc:01 generalised:01 -tuple:01 -tuple:01 generality:01 functorial:01 compiler:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Wednesday 28 April 2004 6:14 pm, skaller wrote: > I have *seen* a heat flow algorithm which can be > tested on a 2D object, and the algorithm then > applied to a 3D object -- without changing anything. I designed and wrote C++ code like this for my PhD in Physics. It was partially specialised over the dimensionality of the Euclidean space and over the tupleness of particle interactions (i.e. n=2 for pair potential etc.). I used C++ templates to perform the partial specialisation. Short of finding and having to work around a bunch of bugs in gcc, the resulting code was reliable and considerably more efficient than unspecialised code. > Just try to do that in C or Fortran or Ocaml. I bet MetaCaml would do a much, much better job than C++. And I bet it wouldn't segfault the compiler. ;-) > You can't. That isn't true, of course. They're all Turing complete so, if the worst comes to the worst, you can write a Fish compiler in C... > In C for example, a typical operation > on a 2D object is a double loop: > > for(i= > for(j= > > but for 3D you need: > > for(i= > for(j= > for(k= The first step in writing such code correctly is to realise that this is a bad way of looking at the problem. You don't want nested loops, you just want a function to propagate computation, whether it be to the next element or to the first element on the next row. Incidentally, there is no performance loss in making this part of the generalisation. > that is, you have no choice implementing generalised > tensor mathematics than to rewrite the program > for every value of n, the rank. That is only true if you approach the problem wrongly. If you approach the problem correctly then you can do everything that you are asking for. > Yet the (tensor) maths is identical and independent > of the rank. I guess there are numerous other > science problems where you do a calc for a certain > set of generalised coordinates .. and then need > to add more coordinates and recalculate .. > only you have to rewrite the program every time. Yes, the ability to write such code is imperative (ho, ho, ho) for scientific code. I found it very useful to debug my algorithms in 2D before using them for production stuff in 3D. > For more general data stuctures of the form > > type 'a x = X of int * 'a | Y of 'a * 'a | Empty > > etc, it is clear how to write a map function. > But each such data structure has a distinct map > function with a distinct type. Yes, for efficiency you want to use a tuple (2-tuple for 2D, 3-tuple for 3D etc.) but for generality you want to use a list. Partial specialisation gives you the best of both worlds. > So clearly .. with functorial polymorphism > you get a LOT more resuable code than at the moment. Not if you do it properly. Cheers, Jon. ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners