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 CAA30356; Fri, 15 Aug 2003 02:13:59 +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 CAA22911 for ; Fri, 15 Aug 2003 02:13:58 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h7F0DuT27238 for ; Fri, 15 Aug 2003 02:13:57 +0200 (MET DST) Received: from localhost (suiren.kurims.kyoto-u.ac.jp [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.9.3p2/3.7W) with ESMTP id JAA28327; Fri, 15 Aug 2003 09:13:44 +0900 (JST) To: qrczak@knm.org.pl Cc: caml-list@inria.fr Subject: Re: [Caml-list] Obj.magic, Obj.t etc. In-Reply-To: <200308141245.13230.qrczak@knm.org.pl> References: <002401c3623d$22c3f2e0$0201a8c0@foorama> <20030814173444D.garrigue@kurims.kyoto-u.ac.jp> <200308141245.13230.qrczak@knm.org.pl> X-Mailer: Mew version 1.94.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Message-Id: <20030815091440Z.garrigue@kurims.kyoto-u.ac.jp> Date: Fri, 15 Aug 2003 09:14:40 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) X-Loop: caml-list@inria.fr X-Spam: no; 0.00; jacques:01 caml-list:01 marcin:01 'qrczak':01 kowalczyk:01 qrczak:01 neutralize:01 functionals:01 leroy's:01 memo:01 monomorphic:01 dynamically:01 arrays:01 semantics:01 garrigue:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: "Marcin 'Qrczak' Kowalczyk" > Dnia czw 14. sierpnia 2003 10:34, Jacques Garrigue napisa=B3: > = > > As a result, the representation of float arrays would not be uniform= , > > requiring a check before access, which would probably neutralize any= > > performance advantage of having a special representation. > = > But now the check is required before polymorphic access. It happens in= inner = > loops in almost all functions from the Array module. True, but you're not supposed to use polymorphic code for high-performance computing. By the way you're not supposed to use functionals either: the prefered approach, according to Xavier Leroy's memo, is monomorphic code and for loops. Of course this limitation only concerns inner loops. My point was that even monomorphic code would need checks, reducing the interest of float arrays to nil. If you want to interpret my point as meaning that the current dynamically distinguished float arrays are a bad idea (costly in polymorphic cases, and limiting the semantics), you're free to do so. I believe some designers of the language think so too. Jacques Garrigue= ------------------- 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