From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 21C66BC2F for ; Fri, 26 Nov 2004 00:35:03 +0100 (CET) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id iAPNZ0FA016037 for ; Fri, 26 Nov 2004 00:35:02 +0100 Received: from [192.168.1.200] (ppp217-171.lns1.syd3.internode.on.net [203.122.217.171]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id iAPNYq4Y091329; Fri, 26 Nov 2004 10:04:53 +1030 (CST) Subject: Re: [Caml-list] Objective Caml release 3.08.2 From: skaller Reply-To: skaller@users.sourceforge.net To: =?ISO-8859-1?Q?Fr=E9d=E9ric?= Gava Cc: caml-list@yquem.inria.fr In-Reply-To: <008001c4d319$693f0f40$b18780d9@mshome.net> References: <75E02BC8-3EEA-11D9-A6E2-00039310CAE8@inria.fr> <004f01c4d2fd$b87d6140$b18780d9@mshome.net> <1101398012.9291.48.camel@pelican.wigram> <008001c4d319$693f0f40$b18780d9@mshome.net> Content-Type: text/plain; charset=UTF-8 Organization: Message-Id: <1101425691.9291.69.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 26 Nov 2004 10:34:52 +1100 Content-Transfer-Encoding: 8bit X-Miltered: at nez-perce with ID 41A66C24.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 sourceforge:01 gava:01 wrote:01 associative:01 associative:01 elt:01 stl:01 hash:01 ocaml:01 glebe:01 ric:98 061:98 nsw:01 constraint:01 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.0 X-Spam-Level: On Fri, 2004-11-26 at 05:05, Frédéric Gava wrote: > > and order matters for folds if the operator being folded > > isn't associative. > Ok. That's right. This is why I thinks, another fold is necessary for > associative operators (and thus for possible optimizations of this fold) and > thus wihtout side-effects. Perhaps that should be a question: are there optimisations which can be performed if the ordering constraint is dropped? This probably has two parts: (a) Is Set.min_elt as fast as Set.choose? (b) Are there any other optimisations (eg deforestation) which would benefit? I don't know the answer to either question in the particular case of Set. Perhaps there would be some benefit for a Set' data type, which was unordered. ISO C++ STL has an ordered Set type (which typically does use a red black tree), and in Technical Report 1 (TR1), there is an unordered set type, intended to be implemented with a hash table. So I would tend to think it may well be worthwhile adding an unordered set to Ocaml. I guess some operations may change from O(log N) to O(1), or from O(N log N) to just O(N), eg fold. -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net