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 UAA03200; Thu, 25 Jul 2002 20:24:30 +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 UAA03144 for ; Thu, 25 Jul 2002 20:24:28 +0200 (MET DST) Received: from relay.pair.com (relay1.pair.com [209.68.1.20]) by nez-perce.inria.fr (8.11.1/8.11.1) with SMTP id g6PIORT04354 for ; Thu, 25 Jul 2002 20:24:27 +0200 (MET DST) Received: (qmail 42580 invoked from network); 25 Jul 2002 18:24:25 -0000 Received: from adsl-host-sf-228.apexworld.net (HELO checkerlap.d6.com) (66.114.212.228) by relay1.pair.com with SMTP; 25 Jul 2002 18:24:25 -0000 X-pair-Authenticated: 66.114.212.228 Message-Id: <4.3.2.7.2.20020725105657.024dbef0@mail.d6.com> X-Sender: checker@mail.d6.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Jul 2002 11:11:08 -0700 To: Xavier Leroy From: Chris Hecker Subject: Re: [Caml-list] Bigarray map & set/get (long) Cc: "O'Caml Mailing List" In-Reply-To: <20020725113049.C23741@pauillac.inria.fr> References: <4.3.2.7.2.20020724194422.028aa970@mail.d6.com> <20020719.155940.19123621.Christophe.Troestler@umh.ac.be> <20020719.155940.19123621.Christophe.Troestler@umh.ac.be> <20020722113136.A10720@pauillac.inria.fr> <4.3.2.7.2.20020724194422.028aa970@mail.d6.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >Agreed, but in this case (as I mentioned in my earlier post) you'd get >better performance by just using regular float arrays rather than >bigarrays.(*) >Thus, I recommend using bigarrays only when interfacing with C or >Fortran numerical code. Sure, but what a pain if you want to do both (say, do some math on an array of floats in caml and then pass them to a graphics api as vertices). Or, you start with an algorithm in caml and then slowly need to move parts of it to C/asm. It would clearly be better if there was a single uniform way to do things that was "optimal" (or close) for both situations. It seems that the bigarray stuff is not far off from this, as I said. There seems to be some nice low hanging fruit that could make a big difference in the native compiler with bigarrays. Anyway, I'll look into it again and do some experiments at some point and see what I come up with. I'd much rather have the caml team working on harder more higher level stuff that I'd have no prayer of being able to do[*], anyway. Chris [*] My current list of needed/wanted language features: 1. operator overloading/generics for making math less ugly and painful 2. module recursion 3. views for pattern matching abstract data types I added views to my want-list relatively recently (6 months ago?) as I started trying to do more interesting stuff. I can't believe the conflict between wanting to pattern match like you're supposed to in ml and wanting to abstract data types like you're supposed to in ml doesn't get more attention in the functional programming community. It seems like a glaring problem, but maybe I'm missing something. ------------------- 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