From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 6CB69BC32 for ; Wed, 16 Mar 2005 14:33:13 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j2GDXCqH018121 for ; Wed, 16 Mar 2005 14:33:12 +0100 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 OAA17408 for ; Wed, 16 Mar 2005 14:33:12 +0100 (MET) Received: from ryxa.irisa.fr (ryxa.irisa.fr [131.254.50.45]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j2GDXClB021113 for ; Wed, 16 Mar 2005 14:33:12 +0100 Received: (from pad@localhost) by ryxa.irisa.fr (8.11.6/8.11.6) id j2GDXAl13650; Wed, 16 Mar 2005 14:33:10 +0100 X-Authentication-Warning: ryxa.irisa.fr: pad set sender to padiolea@irisa.fr using -f Sender: pad@ryxa.irisa.fr To: Oliver Bandel Cc: caml-list@inria.fr Subject: Re: [Caml-list] OCaml troll on Slashdot References: <42363A86.6010309@1969.ws> <200503150859.55997.jon@ffconsultancy.com> <200503152036.45894.jon@ffconsultancy.com> <32977.131.254.50.45.1110920621.squirrel@mail.irisa.fr> <172f01077499b3d417604d0ad31f2bdb@cs.unm.edu> <20050316001819.GB347@first.in-berlin.de> <20050316025532.GA593@first.in-berlin.de> From: Yoann Padioleau Date: 16 Mar 2005 14:33:10 +0100 In-Reply-To: <20050316025532.GA593@first.in-berlin.de> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Miltered: at concorde with ID 42383598.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 42383598.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml:01 irisa:01 oliver:01 bandel:01 oliver:01 in-berlin:01 ocaml:01 imho:01 lazy:01 bandel:01 stack:01 rennes:01 irisa:01 ...:98 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: Oliver Bandel writes: > If he only would be cynic about "well I tried it, but it has proven > it's a crap language... but I give you (experienced OCaml programmers) > the chance to show me that it isn't bad (and *I* have o learn the language)" > then this woul be ok. I agree. > Maybe I'm wrong here and he's a good guy. But IMHO it seems he's looking > for proved Ocaml-failure (and not for "well, I tried it, it seems OCaml sucks, > but please tell me it does not!", which I could accept). I think his intention were good (but he is surely a bad guy too). > Do you think *I'm the bad guy*?! no :) of course not :) > > I am not sure that making the function tail-recursive would have been the big > > hit in this example. > > But as long as nobody tried it / analzed it, your assumption is > only an assumption, as my assumption is only an assumotion too! Well at least my assumption about "use Map instead of assoc list is a big hit" has been proven. The running time from the program go from "more than 16 minutes" to just 50 seconds (this is what I call a big hit). It would be interesting to make his function tail-rec (and keeping the assoc list) and see if it is a big hit but I am too lazy for this and I hate those tail-rec transformation and I think it would not be a big hit cos using Map and Array is the big hit. It's your turn oliver bandel to do the job :) > > I often transform my functions to make them tail-recursive because of stack overflow pb, not > > that much because of speed pbs > > (and many functions in the standard library are not tail-recursive, such as map) > > > Well, maybe I have overestimated the tailrec-point, > but as long as there is not a proven counter-example, > the opposite of what I stated seems to be only an assumption too. True. > > !!! To see different results it would be nice to have different implementations > !!! to compare them all! I agree. > Would be interesting to have different variations of the > code, using different ways of coding some special tasks > in different ways.... and maybe oe implementation, > that uses *all* suggestions. > > To do it in the language shootout, as on Jon stated it, seems > to be a veryg good idea. I agree. I must confess that I have very few intuition about what is more important in optimization, but perhaps because it depends on the program. Sometimes X is a better optimization than Y on this program Z. Sometimes Y is a better optimization than X on this program Z2. > > This tail-recursion stuff is one of the thing I hate the most with fp because it forces > > you to change your code to adapt to the machine whereas it should be the > > inverse. > > But only because you hate it does not mean that changing the code will not result > in better performance. true :) -- Yoann Padioleau, INSA de Rennes, France www.irisa.fr/prive/padiolea/ Opinions expressed here are only mine. Je n'écris qu'à titre personnel. **____ Get Free. Be Smart. Simply use Linux and Free Software. ____**