From: brogoff <brogoff@speakeasy.net>
To: Jim Snow <jsnow@cs.pdx.edu>
Cc: Jon Harrop <jon@ffconsultancy.com>, caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Announce: glome-0.2 (ocaml-based raytracer)
Date: Mon, 15 Jan 2007 10:34:11 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.58.0701151006380.9960@shell2.speakeasy.net> (raw)
In-Reply-To: <45AB57B3.8050800@cs.pdx.edu>
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
next prev parent reply other threads:[~2007-01-15 18:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-12 1:24 Jim Snow
2007-01-12 12:16 ` [Caml-list] " Jon Harrop
2007-01-15 10:30 ` Jim Snow
2007-01-15 18:34 ` brogoff [this message]
2007-01-17 23:01 ` Nathaniel Gray
2007-01-17 23:09 ` Jon Harrop
[not found] ` <200701151206.34251.jon@ffconsultancy.com>
[not found] ` <45ABFB4D.3000605@cs.pdx.edu>
[not found] ` <200701152259.10598.jon@ffconsultancy.com>
2007-01-18 10:29 ` Jim Snow
2007-01-18 14:01 ` Jon Harrop
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.58.0701151006380.9960@shell2.speakeasy.net \
--to=brogoff@speakeasy.net \
--cc=caml-list@yquem.inria.fr \
--cc=jon@ffconsultancy.com \
--cc=jsnow@cs.pdx.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox