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 VAA11924; Thu, 17 Oct 2002 21:53:39 +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 VAA12125 for ; Thu, 17 Oct 2002 21:53:38 +0200 (MET DST) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from epexch01.qlogic.org ([63.170.40.3]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g9HJrbD19612 for ; Thu, 17 Oct 2002 21:53:38 +0200 (MET DST) Received: from epmailtmp.qlogic.org ([10.20.33.254]) by epexch01.qlogic.org with Microsoft SMTPSVC(5.0.2195.4905); Thu, 17 Oct 2002 14:52:32 -0500 Received: from [10.20.33.146] ([10.20.33.146]) by epmailtmp.qlogic.org with Microsoft SMTPSVC(5.0.2195.4905); Thu, 17 Oct 2002 14:53:36 -0500 Date: Thu, 17 Oct 2002 14:59:12 -0500 (CDT) From: Brian Hurt X-X-Sender: Reply-To: Brian Hurt To: Chris Hecker cc: Ocaml Mailing List Subject: Re: [Caml-list] Re: Camlp4 optimizations (was: productivity improvement) In-Reply-To: <4.3.2.7.2.20021017112600.0318b410@mail.d6.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 17 Oct 2002 19:53:36.0713 (UTC) FILETIME=[E1A96B90:01C27616] Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Thu, 17 Oct 2002, Chris Hecker wrote: > The biggest problem with making ocaml look nice and pretty for numerical > code is that there is no overloading (of functions or operators), and > camlp4 doesn't have access to types, so you can't have both: > > s*a (scalar times matrix) > a*b (matrix times matrix) > > What code would the * operator generate in camlp4? This needs to be fixed > at a deeper level than syntax (which is where camlp4 operates...and > operates well! :). Althought hopefully it's fixed in a way that doesn't > require a runtime type-check if the information is available at compile time. > > Or, maybe I'm missing something...it would be awesome if I was and this was > possible! > I'd like to ask a stupid question here: how important is operator overloading? Remember, before you answer, that FORTRAN managed to be crowned king of numerical languages for decades (and may still hold the crown depending upon who you talk to), with no operator or function overloading. You had to call functions with names like cgbmv() (pop quiz- what does that function do?) and dgesvd(). I'm still an ocaml newbie, so I don't know how ocaml handles operator overloading. I do know how C++ handles operator overloading. Consider the 'innocent' statement: a = b + c + d; What you want is for the compiler to produce code like: a = b; a += c; a += d; Instead, what the compiler instead does is: t1 = b + c; t2 = t1 + d; a = t2; generating two unnessecary temporaries. If your objects are complex variables (2 floats) or even short 3D vectors (3 floats) this isn't too bad. If your objects are 10,000 element vectors or matricies, creating two unnecessary temporaries (or even 1 unnecessary temporary) is bad. So why not just code it as: a = b; a += c; a += d; ? Well, I ask- is that code all that much more understandable then: matrix.assign a b ; matrix.addto a c; matrix.addto a d; ? The advantage of operator overloading is the ability to express complex equations "obviously"- a = b + c + d; is way more understandable than the two examples above or: matrix.assign a (matrix.add (matrix.add b c) d) which is the equivelent. But if you can't optimize it, you're just asking to produce bad code. The other cent I'd like to throw into this discussion is a pointer at the OoLaLa project- which is attempting to build a whole new linear algebra library in Java with an OO design (instead of the thin wrappers around FORTRAN-era BLAS libraries and various operator overloading proposals): http://citeseer.nj.nec.com/luj00oolala.html Yes, I know this isn't a functional design. But I'm throwing it out there as a springboard for ideas. Brian ------------------- 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