[Shootout-list] Re: Re: [Shootout-list] Binary trees
Jon Harrop
jon@ffconsultancy.com
Mon, 20 Jun 2005 14:02:38 +0100
The difference is that the C++ has separate structures for spheres and groups,
i.e. a node in the scene tree is either a "Sphere" or a "Group":
struct Scene {
...
};
struct Sphere : public Scene {
Vec center;
double radius;
...
};
typedef list<Scene *> Scenes;
struct Group : public Scene {
Vec center;
double radius;
Scenes child;
...
};
In contrast, the Fortran uses the same data structure for both spheres and
groups, i.e. a node in the scene tree is always of type "Tree":
type Sphere
real*8, dimension(3) :: centre = (/ 0.0d0,0.0d0,0.0d0 /)
real*8 :: radius = 0.0d0
end type Sphere
type Tree
type(Sphere) :: data
type(Tree), pointer :: children(:) => null()
integer :: num_children = 0
end type Tree
On Monday 20 June 2005 11:34, simon@whiteowl.co.uk wrote:
> If the current implementation really is deficient as you describe it
> would be useful to have a specification so that it can be implemented
> as you intend.
I am perfectly happy with the current implementations provided they work. The
deficiency would only show up if the ray tracer were extended, for example to
allow colored spheres, because the most of the implementations allow extra
data like color to be associated only with visible spheres and not with
bounding spheres whereas the Fortran implementation would have to carry an
unused color with every bounding sphere.
> A commented reference implementation should be good
> enough for this - as long as it is in what I would call a normal
> language (java, c++, c#, python, tcl, fortran).
Although I have a C++ program which used the same approach as the Fortran
(because it is shorter), I could not have guessed that the same data
structure could not be implemented in Fortran (or, more precisely, that we
wouldn't know know to implement it).
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists