Re: problem with output of the program on different OS

On May 12, 6:27=A0pm, pereges <Brol...@[EMAIL PROTECTED]
> wrote:
> On May 12, 8:06 pm, Bart <b...@[EMAIL PROTECTED]
> wrote:
>
> > I had a further look at Pelles C version (now that I can run it from
> > the command line, I can make progress..)
>
> > With 3 compilers, ray 463 hits only triangle 654 of the 1200
> > triangles.
> > With Pelles C, ray 463 hits triangles 654 and 745, at equal distances.
>
> I just added a raycount member to ray data structure and kept track of
> rays hitting triangles. I got some what different results. ray 463 is
> hitting triangle 943 at distance 1006.67112
>
> a ray hitting two triangles at same distance is nothing but =A0ray
> hitting the edge shared by two triangles or the vertex.
>
> > Varying your EPSILON made no difference.
>
> Well I =A0varied EPSILON and there was a little difference in output but
> still no where near the results obtained with other compilers.
>
> > So it starts to look more like some strange numeric problem; perhaps
> > Pelles C does some calculations a little differently, or perhaps
> > something more serious; this requires more investigation by someone
> > with a lot more time!
> > It could still be a bug in /your/ calculations which may depend too
> > heavily on some very small value which is treated differently between
> > different C systems.
>
> maybe you are right but isn't it strange that PellesC is the only
> compiler giving a result like this. If there was a serious bug in the
> program, then there would have been atleast one compiler which could
> have given strange result ?

I've narrowed the problem down, it can be illustrated by this code:

double x=3D-10;
double y=3D2.0/3.0;
double z;
unsigned int a=3D15;

z=3Dx+a*y;

printf("%g + %u * %g =3D %g\n", x, a, y, z);

The result (-10+15*(2/3)) should be inexact, and gives something like
1e-15 on most compilers. But Pelles, strangely, gives the exact result
of 0.0!

I'm not going to investigate this further (except out of curiosity to
see what machine code is generated).

In your program, it gives funny near-zero values to some elements of
pointinarray[], which is used to set up .origin of a ray among other
things.

And in one routine, intersect_triangle(), you have *v =3D vector_dot.
This *v is 0.0 in Pelles but something like -1e-15 in the others. You
then reject the intersection when (*v<0.0) which then behaves
differently between the compilers.

(And the same pattern probably occuring in lots of places. So like I
said, you are relying too much on values near zero).

To fix: perhaps clamp those values in pointinarray to 0.0. And in
if(*v<0.0), perhaps use
if(*v<-EPSILON).

> What other languages in your opinion could have been used ? I was told
> C because speed was im****tant to my application.

I'm not the right person to ask; I tend to use my own rapid-
development language. But perhaps Python or similar, anything that is
comfortable with all these points and vectors and with not so many
damn pointers!

--
Bartc