From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=AWL,SPF_SOFTFAIL autolearn=disabled version=3.1.3 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 57A4ABC0C for ; Mon, 15 Jan 2007 19:34:15 +0100 (CET) Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.6]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l0FIYDFp022384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 15 Jan 2007 19:34:14 +0100 Received: (qmail 1103 invoked from network); 15 Jan 2007 18:34:11 -0000 Received: from shell2.sea5.speakeasy.net ([69.17.116.3]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 15 Jan 2007 18:34:11 -0000 Date: Mon, 15 Jan 2007 10:34:11 -0800 (PST) From: brogoff To: Jim Snow Cc: Jon Harrop , caml-list@yquem.inria.fr Subject: Re: [Caml-list] Announce: glome-0.2 (ocaml-based raytracer) In-Reply-To: <45AB57B3.8050800@cs.pdx.edu> Message-ID: References: <45A6E34A.6040007@cs.pdx.edu> <200701121216.40859.jon@ffconsultancy.com> <45AB57B3.8050800@cs.pdx.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Miltered: at concorde with ID 45ABC925.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 compiler:01 recursive:01 recursive:01 uglier:01 recursion:01 2007,:98 polymorphic:01 gpl:01 wrote:01 wrote:01 experimental:01 caml-list:01 functions:01 speakeasy:01 On Mon, 15 Jan 2007, Jim Snow wrote: > Jon Harrop wrote: > > On Friday 12 January 2007 01:24, Jim Snow wrote: > >> I've been working on a raytracer for awhile, and recently decided to > >> remove a lot of experimental code that doesn't work well anyways and > >> release the rest under the gpl version 2. [...snip...] > > I have altered the code to be more idiomatic OCaml, although it is still very > > not-OCaml. I've removed OOP from the hot path and virtual function dispatch > > has been replaced with pattern matches. > > > Sorry I'm a bit slow about replying; I was off trying to implement an > nlogn kd-tree compiler. Your version seems to have sped up the > raytracing by about 10%. However, I think I am going to stick with my > approach for the time being for the sake of maintainability; I don't > think putting all the ray-intersection code together in one > mutually-recursive is going to make the program easy to modify in the > future. I am tempted though. I might also give recursive modules a try. I haven't coded a ray tracer in a long time, and the one I did was for a college class, but my recollection is that even in C (the implementation language I used) the design used classes/objects for the primitives, so that one could add new primitives and the only piece of code that would need modification would be the interpreter of scene description files. I think using classes for that is the right approach. I'm sure you could do it in a more coreish ML fashion without even using recursive modules, say by emulating the OO in C approach with ML records of functions, but it won't be any faster and will be uglier, since the class system provides a kind of generalized polymorphic record. This is a nice example for discussing the merits of OO features, and less complex than the expression problem. A competitive "non-OO" approach should provide easy extensibility along the same axes as the OO one. I admit I don't see the need for cross file recursion here. -- Brian