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 XAA27202; Tue, 21 May 2002 23:06:53 +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 XAA27182 for ; Tue, 21 May 2002 23:06:52 +0200 (MET DST) Received: from mbg.sphere.ne.jp (mbg.sphere.ne.jp [210.150.254.179]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g4LL6oX26520 for ; Tue, 21 May 2002 23:06:50 +0200 (MET DST) Received: from localhost (pl047.nas521.k-tokyo.nttpc.ne.jp [210.165.66.47]) by mbg.sphere.ne.jp (Postfix) with ESMTP id EF51F3A28F; Wed, 22 May 2002 06:06:46 +0900 (JST) In-Reply-To: <20020516170347.GA25822@kiefer.ai.univie.ac.at> References: <20020517010515L.yoriyuki@mbg.sphere.ne.jp> <20020516170347.GA25822@kiefer.ai.univie.ac.at> Subject: Re: [Caml-list] Surreal-0.0.3 To: markus@oefai.at Cc: caml-list@inria.fr X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20020521211128T.yoriyuki@mbg.sphere.ne.jp> Date: Tue, 21 May 2002 21:11:28 +0900 From: YAMAGATA yoriyuki X-Dispatcher: imput version 991025(IM133) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: Markus Mottl Subject: Re: [Caml-list] Surreal-0.0.3 Date: Thu, 16 May 2002 19:03:47 +0200 > The only problem of such a library might be its efficiency... A pioneer work by B=F6hm et al shows that a naive approach using functions as reals achieves better performance than a lazy approach (at least the one using infinite n-base expansion). The main point of Surreal is performance. (So, I don't use lazy approaches.) I tried some idea to boost performance for large scale computation. Another reason I was discouraged is that I don't know how to show the performance improvement. I hope someone who has experience with numerical computation looks my idea and judges whether it is useful. Yet another problem I have encountered is memory exhaustion. In my experiment, memory is major limitation (rather time). caml lazy construct always memorizes values, so one may encounter a similar problem. Haskel or other lazy languages may have better space efficiency, though. That's my thought. -- Yamagata Yoriyuki http://www.mars.sphere.ne.jp/yoriyuki/ ------------------- 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