problem with output of the program on different OS

[pereges]

I have a C program which I created on Windows machine. I have compiled
and executed the program on windows machine and it gives me the
consistent output every time i run it. for eg.

input a = 2, b =3

lets say a sum operation is to be performed, then:

output: 5

The output is always consistent and correct with regards to input.

I tried to run the program on my linux machine. The program compiles
and executes but I'm getting strange results. For eg. for the problem
of addition above:

input a = 2 b = 3

output: 1

i execute the program again:

input a = 2 b = 3

output: 6

and again:

input a = 2 b= 3

output 0

What is happening ?

[pete]

dj******@csclub.uwaterloo.ca.invalid wrote:

In article <3f**********************************@c58g2000hsc. googlegroups.com>,
Bart <[e-mail]:

>On May 10, 1:24 pm, Richard Heathfield <[e-mail]:

>>I haven't got as far as executing it yet. When I get some more time, I'll
do some more code clean-up. When eventually I get around to executing it,
I'll post the result here.

Is it some principle of yours that you never execute any code until
every possible warning has been eliminated and it has been styled
entirely to your satisfaction?

Sounds a bit like premature optimisation to me (when you eventually
run it you find you have to change all that beautifully crafted code).

I can't speak for RH, but I never execute code until I have at least
reasonable confidence that it will do something not entirely unlike
what I expect. The sooner you find and fix errors, the easier it is,
and it's hard to catch coding errors much sooner than "before you run
the code" (though design errors can often be caught before you even
start writing the code).

Eliminating compiler warnings and, for many (but far from all)
stylistic preferences, modifying code to conform to those stylistic
preferences is one way (and a rather cost-effective one when done well)
to increase the level of confidence that the code will do something not
entirely unlike what the programmer expects.

When I test and correct code that other people post to this group,
if it generates warnings, I change it before I test it.

Those changes would be part of the corrections anyway.

--
pete

[Richard Heathfield]

Richard Heathfield said:

<snip>

If I get the time, I'll continue this review exercise later.

Well, I don't hold out a lot of hope for this review, judging by the OP's
reply to the first part thereof ("I think this is not the problem", for
instance, shows a remarkable talent for disregarding general-principle
comments simply because they don't appear to explain the immediate cause
of the immediate segfault - if ever there were a short-sighted approach to
debugging, this has to be it).

Nevertheless, let's press on for now.

I fixed the scanfs in initialize_radar(), checking the return values and
returning FAILURE if they were incorrect. (As mentioned in my earlier
article, I also C90ified and re-indented the code, purely for my own
convenience.) The function now looks like this:

int initialize_radar(bbox b,
radar_detector * radar)
{
int rc = SUCCESS;
vector *pointinarray = NULL;
int i;
unsigned long int ray_count;

radar->maxP = b.maxB;
radar->minP = b.minB;
radar->maxP.z = radar->minP.z = b.minB.z - 1000;

printf
("Enter the frequency of the electromagnetic rays to be fired\n");
if(scanf("%le", &radar->frequency) != 1)
{
rc = FAILURE;
}
else
{
radar->wavenumber = 2 * M_PI * radar->frequency / VELOCITY;

printf("Enter the amplitude of electric field\n");
if(scanf("%le", &radar->E0) != 1)
{
rc = FAILURE;
}
}

if(rc == SUCCESS)
{
printf("Enter the number of electromagnetic rays to be fired\n");
if(scanf("%lu", &radar->numberofrays) != 1)
{
rc = FAILURE;
}
}

if(rc == SUCCESS)
{
real(radar->E_incident) = 0;
imag(radar->E_scattered) = 0;

i =
gen_grid_points(&pointinarray, &radar->numberofrays, b.maxB.x,
b.minB.x, b.maxB.y, b.minB.y, b.minB.z - 1000);
if(i == FAILURE)
{
rc = FAILURE;
}
}
if(rc == SUCCESS)
{
ray_count = radar->numberofrays;
radar->raylist = malloc(ray_count * sizeof (ray));
if(radar->raylist == NULL)
{
perror("malloc has failed");
rc = FAILURE;
}
}

if(rc == SUCCESS)
{
for(ray_count = 0; ray_count < radar->numberofrays; ray_count++)
{
radar->raylist[ray_count].origin = pointinarray[ray_count];
radar->raylist[ray_count].direction.x = 0;
radar->raylist[ray_count].direction.y = 0;
radar->raylist[ray_count].direction.z = 1;
radar->raylist[ray_count].depth = 0;
radar->raylist[ray_count].pathlength = DBL_MAX;
radar->raylist[ray_count].child = NULL;
real(radar->raylist[ray_count].efield) = radar->E0;
imag(radar->raylist[ray_count].efield) = 0;
}
}

free(pointinarray);

return rc;

}

This source file (radar.c) now gives just two diagnostic messages, both to
do with passing an unsigned long int to sqrt. (Yes, I killed my insertion
of assert(*numpoints >= 0, now that I realise *numpoints has unsigned
integer type.

Continuing on my quest to get the diagnostic count down a bit, I moved on
to reader.c. Simply moving the definitions of temporary vectors up to the
top of the function, I made the code C90-compatible. The remaining
warnings are:

reader.c:68: warning: passing arg 2 of `calloc' as unsigned due to
prototype
reader.c:69: warning: passing arg 2 of `calloc' as unsigned due to
prototype
reader.c:109: warning: enumeration value `LAST_LINE' not handled in switch

Although I don't like the first two, I can live with them if you can - the
alternative (i.e. to use unsigned types for nvert and ntri) may be more
painful to fix than is practical (I haven't delved).

The last one, I leave in your hands. I'm not making any huge attempt to
understand the program here - I'm just looking at the C.

I needed to C90ify the test.c file, changing a comment to /* style */ and
moving a definition up a bit. The reflection.c file also needed some
comment-fixing.

Now it compiles. It doesn't /link/, but that's my makefile's problem, not
yours. So let's run it:

$ ./raytrace
Enter the frequency of the electromagnetic rays to be fired

Well, I have no idea what to type here, so I just entered 0 for everything,
and lo and behold, I got an assertion failure:

raytrace: radar.c:49: gen_grid_points: Assertion `numpointsx 1' failed.

I added this assertion because your code assumed that numpointsx could not
be 1 or lower. That assumption is clearly wrong.

I suggest you fix this (by validating your data before passing it to the
function that needs it to be 1). If the code continues to give problems
after that's fixed, show us the fixed code so that we know that this
particular problem is known not to be a candidate any longer.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Spiros Bousbouras]

On 12 May, 02:35, Richard Heathfield <[e-mail]:

Richard Heathfield said:
The remaining
warnings are:

reader.c:68: warning: passing arg 2 of `calloc' as unsigned due to
prototype
reader.c:69: warning: passing arg 2 of `calloc' as unsigned due to
prototype
reader.c:109: warning: enumeration value `LAST_LINE' not handled in switch

Although I don't like the first two, I can live with them if you can - the
alternative (i.e. to use unsigned types for nvert and ntri) may be more
painful to fix than is practical (I haven't delved).

The last one, I leave in your hands. I'm not making any huge attempt to
understand the program here - I'm just looking at the C.

I believe the last warning is not a problem , the LAST_LINE
thing is the condition of the while loop.

I needed to C90ify the test.c file, changing a comment to /* style */ and
moving a definition up a bit. The reflection.c file also needed some
comment-fixing.

Now it compiles. It doesn't /link/, but that's my makefile's problem, not
yours.

You wrote a makefile for such a simple project ?
I just did (on Linux) cc -Wall *.c -lm

So let's run it:

$ ./raytrace
Enter the frequency of the electromagnetic rays to be fired

Well, I have no idea what to type here...

But elsethread the OP specifies which values you
should enter for all the questions.

...so I just entered 0 for everything,
and lo and behold, I got an assertion failure:

raytrace: radar.c:49: gen_grid_points: Assertion `numpointsx 1' failed.

I added this assertion because your code assumed that numpointsx could not
be 1 or lower. That assumption is clearly wrong.

I suggest you fix this (by validating your data before passing it to the
function that needs it to be 1). If the code continues to give problems
after that's fixed, show us the fixed code so that we know that this
particular problem is known not to be a candidate any longer.

[pereges]

On May 10, 12:43 am, Bart <[e-mail]:

Out of 4 Windows C compilers:

lccwin32, gcc, dmc all give: 7.39, 1.11, 8.35 (ignoring exponents)

I got the oppurtunity to execute the code on linux today (using gcc
compiler) and I'm getting exactly this result i.e.:

Enter the frequency of the electromagnetic rays to be fired
40e+7
Enter the amplitude of electric field
10e-4
Enter the number of electromagnetic rays to be fired
1000
Es: 7.391785e-11 Ei: 1.112194e-04 RCS: 8.351773e+00

>
Pelles C gives: 7.08, 7.95, 1.11 same as you.

Time to suspect Pelles C I think! What are the results on linux?

If you can get at least one more compiler that gives my figures, it's
then easy to print out radar.E_scattered say and see where they
diverge.

But it's also possible there's a bug in Pelles C.

Right now, it seems PellesC is the only one giving a different result.

[pereges]

On May 12, 6:35 am, Richard Heathfield <[e-mail]:

Well, I don't hold out a lot of hope for this review, judging by the OP's
reply to the first part thereof ("I think this is not the problem", for
instance, shows a remarkable talent for disregarding general-principle
comments simply because they don't appear to explain the immediate cause
of the immediate segfault - if ever there were a short-sighted approach to
debugging, this has to be it).

well, i did include the assert(index >= 0) statement in the code but
while executing the assertion fails. What I'm trying to say is that
this is natural because index is bound to have value -1 for cases
where ray does not intersect the triangle. Also res.hit = FALSE for
such situations.

Nevertheless, let's press on for now.

I fixed the scanfs in initialize_radar(), checking the return values and
returning FAILURE if they were incorrect. (As mentioned in my earlier
article, I also C90ified and re-indented the code, purely for my own
convenience.) The function now looks like this:

int initialize_radar(bbox b,
radar_detector * radar)
{
int rc = SUCCESS;
vector *pointinarray = NULL;
int i;
unsigned long int ray_count;

radar->maxP = b.maxB;
radar->minP = b.minB;
radar->maxP.z = radar->minP.z = b.minB.z - 1000;

printf
("Enter the frequency of the electromagnetic rays to be fired\n");
if(scanf("%le", &radar->frequency) != 1)
{
rc = FAILURE;
}
else
{
radar->wavenumber = 2 * M_PI * radar->frequency / VELOCITY;

printf("Enter the amplitude of electric field\n");
if(scanf("%le", &radar->E0) != 1)
{
rc = FAILURE;
}
}

if(rc == SUCCESS)
{
printf("Enter the number of electromagnetic rays to be fired\n");
if(scanf("%lu", &radar->numberofrays) != 1)
{
rc = FAILURE;
}
}

if(rc == SUCCESS)
{
real(radar->E_incident) = 0;
imag(radar->E_scattered) = 0;

i =
gen_grid_points(&pointinarray, &radar->numberofrays, b.maxB.x,
b.minB.x, b.maxB.y, b.minB.y, b.minB.z - 1000);
if(i == FAILURE)
{
rc = FAILURE;
}
}
if(rc == SUCCESS)
{
ray_count = radar->numberofrays;
radar->raylist = malloc(ray_count * sizeof (ray));
if(radar->raylist == NULL)
{
perror("malloc has failed");
rc = FAILURE;
}
}

if(rc == SUCCESS)
{
for(ray_count = 0; ray_count < radar->numberofrays; ray_count++)
{
radar->raylist[ray_count].origin = pointinarray[ray_count];
radar->raylist[ray_count].direction.x = 0;
radar->raylist[ray_count].direction.y = 0;
radar->raylist[ray_count].direction.z = 1;
radar->raylist[ray_count].depth = 0;
radar->raylist[ray_count].pathlength = DBL_MAX;
radar->raylist[ray_count].child = NULL;
real(radar->raylist[ray_count].efield) = radar->E0;
imag(radar->raylist[ray_count].efield) = 0;
}
}

free(pointinarray);

return rc;

}

This source file (radar.c) now gives just two diagnostic messages, both to
do with passing an unsigned long int to sqrt. (Yes, I killed my insertion
of assert(*numpoints >= 0, now that I realise *numpoints has unsigned
integer type.

Continuing on my quest to get the diagnostic count down a bit, I moved on
to reader.c. Simply moving the definitions of temporary vectors up to the
top of the function, I made the code C90-compatible. The remaining
warnings are:

reader.c:68: warning: passing arg 2 of `calloc' as unsigned due to
prototype
reader.c:69: warning: passing arg 2 of `calloc' as unsigned due to
prototype
reader.c:109: warning: enumeration value `LAST_LINE' not handled in switch

Although I don't like the first two, I can live with them if you can - the
alternative (i.e. to use unsigned types for nvert and ntri) may be more
painful to fix than is practical (I haven't delved).

The last one, I leave in your hands. I'm not making any huge attempt to
understand the program here - I'm just looking at the C.

I needed to C90ify the test.c file, changing a comment to /* style */ and
moving a definition up a bit. The reflection.c file also needed some
comment-fixing.

Now it compiles. It doesn't /link/, but that's my makefile's problem, not
yours. So let's run it:

$ ./raytrace
Enter the frequency of the electromagnetic rays to be fired

Well, I have no idea what to type here, so I just entered 0 for everything,
and lo and behold, I got an assertion failure:

raytrace: radar.c:49: gen_grid_points: Assertion `numpointsx 1' failed.

I added this assertion because your code assumed that numpointsx could not
be 1 or lower. That assumption is clearly wrong.

I suggest you fix this (by validating your data before passing it to the
function that needs it to be 1). If the code continues to give problems
after that's fixed, show us the fixed code so that we know that this
particular problem is known not to be a candidate any longer.

thanks i will try to incorporate the changes you have suggested

[Richard Heathfield]

pereges said:

On May 12, 6:35 am, Richard Heathfield <[e-mail]:

>Well, I don't hold out a lot of hope for this review, judging by the
OP's reply to the first part thereof ("I think this is not the problem",
for instance, shows a remarkable talent for disregarding
general-principle comments simply because they don't appear to explain
the immediate cause of the immediate segfault - if ever there were a
short-sighted approach to debugging, this has to be it).

well, i did include the assert(index >= 0) statement in the code but
while executing the assertion fails. What I'm trying to say is that
this is natural because index is bound to have value -1 for cases
where ray does not intersect the triangle. Also res.hit = FALSE for
such situations.

For The Very Last Time: in the code as it existed at the time you wrote it,
in cases where no intersections took place, you were attempting to
evaluate an object whose value was indeterminate and therefore could not
be evaluated. To do so invokes undefined behaviour.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Bart]

On May 12, 10:17*am, pereges <[e-mail]:

On May 10, 12:43 am, Bart <[e-mail]:

But it's also possible there's a bug in Pelles C.

Right now, it seems PellesC is the only one giving a different result.

Been trying to investigate further, but's it's getting more complex
and Pelles' IDE is a right pain to use.

The figures for radar->E_scattered start to divulge at ray_count=463
(they are the same at ray_count=462).

The immediate culprit is r.pathlength, but this is traced to
intersect_triangle(). I stored the last det value calculated in
intersect_triangle, and the results were for ray_count=462, 463, 464:

0.550692 0.550692 0.329331 on main compilers
0.550692 0.329331 0.329331 on Pelles C

Why is the middle one different? Might be a different pattern of
calling intersect_triangle(), which is where it starts to get
complicated.

Perhaps you should forget Pelles C. You might do a lot of work just to
discover some obscure bug in the compiler (on the other hand, you
might well find some undefined behaviour in your program and maybe all
the results were wrong).
--
Bartc

[pereges]

Bart wrote:

Been trying to investigate further, but's it's getting more complex
and Pelles' IDE is a right pain to use.

The figures for radar->E_scattered start to divulge at ray_count=463
(they are the same at ray_count=462).

The immediate culprit is r.pathlength, but this is traced to
intersect_triangle(). I stored the last det value calculated in
intersect_triangle, and the results were for ray_count=462, 463, 464:

0.550692 0.550692 0.329331 on main compilers
0.550692 0.329331 0.329331 on Pelles C

Why is the middle one different? Might be a different pattern of
calling intersect_triangle(), which is where it starts to get
complicated.

Perhaps you should forget Pelles C. You might do a lot of work just to
discover some obscure bug in the compiler (on the other hand, you
might well find some undefined behaviour in your program and maybe all
the results were wrong).

I really don't know and now its not even the question of incorrect
output on different operating systems. Now, when I run the code on
linux, I get the same output everytime for the same set of input(this
was a problem previously).

[Bart]

On May 12, 2:29*pm, pereges <[e-mail]:

Bart wrote:

Been trying to investigate further, but's it's getting more complex
and Pelles' IDE is a right pain to use.

The figures for radar->E_scattered start to divulge at ray_count=463
(they are the same at ray_count=462).

The immediate culprit is r.pathlength, but this is traced to
intersect_triangle(). I stored the last det value calculated in
intersect_triangle, and the results were for ray_count=462, 463, 464:

0.550692 0.550692 0.329331 on main compilers
0.550692 0.329331 0.329331 on Pelles C

Why is the middle one different? Might be a different pattern of
calling intersect_triangle(), which is where it starts to get
complicated.

Perhaps you should forget Pelles C. You might do a lot of work just to
discover some obscure bug in the compiler (on the other hand, you
might well find some undefined behaviour in your program and maybe all
the results were wrong).

I really don't know and now its not even the question of incorrect
output on different operating systems. Now, when I run the code on
linux, I get the same output everytime for the same set of input(this
was a problem previously).- Hide quoted text -

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.

Varying your EPSILON made no difference.

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.

BTW this is a hell of a complicated program; I wouldn't have used C
for this. Not until it was 100% working with some reference results
anyway. (I(/we?) still don't know what the right output is supposed to
be. Makes testing a little difficult!)

--
Bartc

[pereges]

On May 12, 8:06 pm, Bart <[e-mail]:

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 ray
hitting the edge shared by two triangles or the vertex.

Varying your EPSILON made no difference.

Well I varied 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 ?

BTW this is a hell of a complicated program; I wouldn't have used C
for this. Not until it was 100% working with some reference results
anyway. (I(/we?) still don't know what the right output is supposed to
be. Makes testing a little difficult!)

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

[Ben Bacarisse]

pereges <Br*****@gmail.comwrites:

Bart wrote:

>Been trying to investigate further, but's it's getting more complex
and Pelles' IDE is a right pain to use.

The figures for radar->E_scattered start to divulge at ray_count=463
(they are the same at ray_count=462).

The immediate culprit is r.pathlength, but this is traced to
intersect_triangle(). I stored the last det value calculated in
intersect_triangle, and the results were for ray_count=462, 463, 464:

0.550692 0.550692 0.329331 on main compilers
0.550692 0.329331 0.329331 on Pelles C

Why is the middle one different? Might be a different pattern of
calling intersect_triangle(), which is where it starts to get
complicated.

Perhaps you should forget Pelles C. You might do a lot of work just to
discover some obscure bug in the compiler (on the other hand, you
might well find some undefined behaviour in your program and maybe all
the results were wrong).

I really don't know and now its not even the question of incorrect
output on different operating systems. Now, when I run the code on
linux, I get the same output everytime for the same set of input(this
was a problem previously).

This is not a good way to debug a program. Did you fix (or disprove)
the apparent bug that I pointed out? Using uninitialised data would
explain all the variation in results.

The probability of finding a compiler bug in language X is roughly

(epsilon + no. of years you've been programming in X)/N

(for some small epsilon and large N) :-)

--
Ben.

[Bart]

On May 12, 6:27*pm, pereges <[e-mail]:

On May 12, 8:06 pm, Bart <[e-mail]:

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 *ray
hitting the edge shared by two triangles or the vertex.

Varying your EPSILON made no difference.

Well I *varied 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=-10;
double y=2.0/3.0;
double z;
unsigned int a=15;

z=x+a*y;

printf("%g + %u * %g = %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 = 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 important 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

[Ben Bacarisse]

Bart <[e-mail]:

On May 12, 6:27Â*pm, pereges <[e-mail]:

<snip>

>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 ?

No, you can't reason like that. It seems to me that there is a clear
and obvious bug in the program (unless you are now working from a
newer fixed version). Since I seem to shouting from the sidelines
here let me rephrase it: the automatic variable (radar_detector radar)
seems to be only partially initialised buy the function
'initialize_radar'. This is quite sufficient to explain what you see.
You don't need to blame a compiler.

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

double x=-10;
double y=2.0/3.0;
double z;
unsigned int a=15;

z=x+a*y;

printf("%g + %u * %g = %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!

What is odd about that? My gcc does exactly the same. It
seems entirely correct to me.

Either way, it should not be the explanation. If the physics of the
program are reasonable (and correct) the results will be roughly the
same. Only the most ill-conditioned problems will diverge due such
problems. If this is such a case (and I am pretty sure it is not) the
solution lies not in the compiler that gives z = 1e-15 rather than 0
but rather in a new algorithm that is more stable.

--
Ben.

[Bart]

On May 13, 1:39*am, Ben Bacarisse <[e-mail]:

Bart <[e-mail]:

On May 12, 6:27*pm, pereges <[e-mail]:

<snip>

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 ?

No, you can't reason like that. *It seems to me that there is a clear
and obvious bug in the program (unless you are now working from a
newer fixed version). *Since I seem to shouting from the sidelines
here let me rephrase it: the automatic variable (radar_detector radar)
seems to be only partially initialised buy the function
'initialize_radar'. *This is quite sufficient to explain what you see.
You don't need to blame a compiler.

One specific initialisation problem was mentioned upthread; there
seemed to be others, but not directly affecting the Pelles C result I
was tracing.

>

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

double x=-10;
double y=2.0/3.0;
double z;
unsigned int a=15;

z=x+a*y;

printf("%g + %u * %g = %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!

What is odd about that? *My gcc does exactly the same. *It
seems entirely correct to me.

I would expect the answer to be wrong by one bit or so. My gcc/3.4.5
gives -5e-16.

I was intrigued in why 1 compiler out of 4 gave a different result,
and tracked it down to this behaviour (it was also more interesting
than what I was supposed to be doing..)

>
Either way, it should not be the explanation. *If the physics of the
program are reasonable (and correct) the results will be roughly the
same. *Only the most ill-conditioned problems will diverge due such
problems. *If this is such a case (and I am pretty sure it is not) the
solution lies not in the compiler that gives z = 1e-15 rather than 0
but rather in a new algorithm that is more stable.

Yes the program is unstable if it can give different results depending
on whether one value is just one side of zero or the other. As it is I
wouldn't now trust any of the results to be correct even if many
concur.

This is up to the OP now to fix the problems.

--
Bartc

[Ben Bacarisse]

Bart <[e-mail]:

On May 13, 1:39Â*am, Ben Bacarisse <[e-mail]:

>Bart <[e-mail]:

On May 12, 6:27Â*pm, pereges <[e-mail]:

<snip>

>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 ?

No, you can't reason like that. Â*It seems to me that there is a clear
and obvious bug in the program (unless you are now working from a
newer fixed version). Â*Since I seem to shouting from the sidelines
here let me rephrase it: the automatic variable (radar_detector radar)
seems to be only partially initialised buy the function
'initialize_radar'. Â*This is quite sufficient to explain what you see.
You don't need to blame a compiler.

One specific initialisation problem was mentioned upthread; there
seemed to be others, but not directly affecting the Pelles C result I
was tracing.

I can't see how leaving parts of a complex number (that is used)
uninitialised could not be affecting what you were tracing. Maybe I
am missing what you are tracing, but the program seems use
uninitialised data, specifically the real part of the E_scattered
member and the imaginary part of E_incident member of the radar
structure (as posted /three days ago/[1]).

Now, the OP may have corrected that, and you may be using that
corrected source, but there was no "OK, fixed" message from him so I
suspect not. It is also possible that my reasoning is wrong, but then
I'd expect a message saying "it's OK, I set it here" or "I never use
the real part of E_scattered").

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

double x=-10;
double y=2.0/3.0;
double z;
unsigned int a=15;

z=x+a*y;

printf("%g + %u * %g = %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!

What is odd about that? Â*My gcc does exactly the same. Â*It
seems entirely correct to me.

I would expect the answer to be wrong by one bit or so. My gcc/3.4.5
gives -5e-16.

Mine is 4.2.3. The point is I think 0 is a correct and permitted
answer. It is not at all strange (to me).

This has got so surreal that I have just downloaded Pelles C. If I
leave the bug in I get this output:

Es: inf Ei: 1.112194e-04 RCS: inf

If I correct it by setting the missing parts of the complex numbers to
0 I get this:

Es: 7.391785e-11 Ei: 1.112194e-04 RCS: 8.351773e+00

which is exactly what gcc 4.2.3 and lcc-win32 give me. It seems to be
a bug of the most ordinary nature.

I was intrigued in why 1 compiler out of 4 gave a different result,
and tracked it down to this behaviour

I am far from sure that you have. Does the version you traced have
uninitialised data and does the problem remain when you add the two
extra zero initialisations? If, so I will agree it looks odd, but so
far it seems to be a common all-garden bug in the code.

[1] Message-ID: <87************@bsb.me.uk>

--
Ben.

[pereges]

On May 12, 10:44 pm, Ben Bacarisse <[e-mail]:

pereges <[e-mail]:

Bart wrote:

Been trying to investigate further, but's it's getting more complex
and Pelles' IDE is a right pain to use.

The figures for radar->E_scattered start to divulge at ray_count=463
(they are the same at ray_count=462).

The immediate culprit is r.pathlength, but this is traced to
intersect_triangle(). I stored the last det value calculated in
intersect_triangle, and the results were for ray_count=462, 463, 464:

0.550692 0.550692 0.329331 on main compilers
0.550692 0.329331 0.329331 on Pelles C

Why is the middle one different? Might be a different pattern of
calling intersect_triangle(), which is where it starts to get
complicated.

Perhaps you should forget Pelles C. You might do a lot of work just to
discover some obscure bug in the compiler (on the other hand, you
might well find some undefined behaviour in your program and maybe all
the results were wrong).

I really don't know and now its not even the question of incorrect
output on different operating systems. Now, when I run the code on
linux, I get the same output everytime for the same set of input(this
was a problem previously).

This is not a good way to debug a program. Did you fix (or disprove)
the apparent bug that I pointed out? Using uninitialised data would
explain all the variation in results.

The probability of finding a compiler bug in language X is roughly

(epsilon + no. of years you've been programming in X)/N

(for some small epsilon and large N) :-)

Yes, I fixed the bug that you had pointed out( uninitialized members
of E_incident and E_scattered) and other bugs that many people have
pointed out. Because of these changes, I'm now getting a different and
consistent result on most compilers. Other people are also getting the
same result as me now. Strangely, only pellesC is reporting a
different result which is similar to the result I had before the bugs
were fixed. It doesn't seem to be affected by the changes.

[pereges]

On May 13, 8:46 am, Ben Bacarisse <[e-mail]:

If I correct it by setting the missing parts of the complex numbers to
0 I get this:

Es: 7.391785e-11 Ei: 1.112194e-04 RCS: 8.351773e+00

which is exactly what gcc 4.2.3 and lcc-win32 give me. It seems to be
a bug of the most ordinary nature.

I was intrigued in why 1 compiler out of 4 gave a different result,
and tracked it down to this behaviour

I am far from sure that you have. Does the version you traced have
uninitialised data and does the problem remain when you add the two
extra zero initialisations? If, so I will agree it looks odd, but so
far it seems to be a common all-garden bug in the code.

Are you really getting this output on PellesC after fixing the bug?
What is the version ? I'm using PellesC 5.00.4 and it reports the same
value 1.11e+01

[Bart]

On May 13, 4:46*am, Ben Bacarisse <[e-mail]:

Bart <[e-mail]:

On May 13, 1:39*am, Ben Bacarisse <[e-mail]:

Bart <[e-mail]:
On May 12, 6:27*pm, pereges <[e-mail]:

I would expect the answer to be wrong by one bit or so. My gcc/3.4.5
gives -5e-16.

Mine is 4.2.3. *The point is I think 0 is a correct and permitted
answer. *It is not at all strange (to me).

This has got so surreal that I have just downloaded Pelles C. *If I
leave the bug in I get this output:

Es: inf Ei: 1.112194e-04 RCS: inf

I was also getting these weird results. I independently made the
initialisation change and got the results of 7.39... except for Pelles
which gave 7.08...;

>
If I correct it by setting the missing parts of the complex numbers to
0 I get this:

Es: 7.391785e-11 Ei: 1.112194e-04 RCS: 8.351773e+00

which is exactly what gcc 4.2.3 and lcc-win32 give me. *It seems to be
a bug of the most ordinary nature.

My Pelles and the OP's gave 7.08....

In fact my Pelles was an old V2.9, I just downloaded the new version
and it gave the same results, namely 7.08.

I was intrigued in why 1 compiler out of 4 gave a different result,
and tracked it down to this behaviour

I am far from sure that you have. *Does the version you traced have
uninitialised data and does the problem remain when you add the two
extra zero initialisations? *If, so I will agree it looks odd, but so
far it seems to be a common all-garden bug in the code.

There's lots of other uninitialised data which may or may not be
affecting anything else. However the 7.08/7.39 discrepancy *was*
traced to these zero/near zero values.

But I've now changed a couple of things: < 0.0 to < (-EPSILON) and >
1.0 to (1+EPSILON).

*Now*, all my 4 compilers (5 including new Pelles) give the 7.08...
result.

(Whether that is right or not, I've still no idea.)
--
Bartc

[Chris Dollin]

Richard wrote:

Richard Heathfield <rj*@see.sig.invalidwrites:

>Debuggers are over-rated by some people, and can be a huge time sink if
used flailingly.

What total and utter nonsense.

You're claiming that no-one over-rates debuggers, and that even if
used flailingly are never time-sinks. Both claims seem to be
implausible.

I think your knee is jerking.

--
/Questions? Answers! Answers? Questions!/ - Focus

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

[Ben Bacarisse]

pereges <Br*****@gmail.comwrites:

Yes, I fixed the bug that you had pointed out( uninitialized members
of E_incident and E_scattered) and other bugs that many people have
pointed out.

Did I miss the message where you explained that?

--
Ben.

[Ben Bacarisse]

pereges <Br*****@gmail.comwrites:

On May 13, 8:46 am, Ben Bacarisse <[e-mail]:

>If I correct it by setting the missing parts of the complex numbers to
0 I get this:

Es: 7.391785e-11 Ei: 1.112194e-04 RCS: 8.351773e+00

which is exactly what gcc 4.2.3 and lcc-win32 give me. It seems to be
a bug of the most ordinary nature.

I was intrigued in why 1 compiler out of 4 gave a different result,
and tracked it down to this behaviour

I am far from sure that you have. Does the version you traced have
uninitialised data and does the problem remain when you add the two
extra zero initialisations? If, so I will agree it looks odd, but so
far it seems to be a common all-garden bug in the code.

Are you really getting this output on PellesC after fixing the bug?

Yes.

What is the version ?

4.50.113

I'm using PellesC 5.00.4 and it reports the same value 1.11e+01

--
Ben.

[pereges]

On May 13, 5:12 pm, Ben Bacarisse <[e-mail]:

pereges <[e-mail]:

Yes, I fixed the bug that you had pointed out( uninitialized members
of E_incident and E_scattered) and other bugs that many people have
pointed out.

Did I miss the message where you explained that?

I had missed your post in 2nd page but I think BartC also pointed out
that bug. I replied to him on page 2.

[Richard Heathfield]

Chris Dollin said:

Richard wrote:

>Richard Heathfield <rj*@see.sig.invalidwrites:

>>Debuggers are over-rated by some people, and can be a huge time sink if
used flailingly.

What total and utter nonsense.

You're claiming that no-one over-rates debuggers, and that even if
used flailingly are never time-sinks. Both claims seem to be
implausible.

Good Lord, that was months ago, wasn't it? Well, days ago, anyway. Is he
the tardy one, or are you? :-)

I think your knee is jerking.

<shrugYou expected something different? Remember that the above idiocy
hails from the same stable that can't distinguish between "I rarely do
such-and-such" and "I never do such-and-such", or between "I have on a few
rare occasions been able to do so-and-so" and "I can always do so-and-so".
Time spent arguing with such people is generally time wasted (which
doesn't necessarily mean it can't be fun).

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Ben Bacarisse]

Bart <[e-mail]:

On May 13, 4:46Â*am, Ben Bacarisse <[e-mail]:

>Bart <[e-mail]:

On May 13, 1:39Â*am, Ben Bacarisse <[e-mail]:
Bart <[e-mail]:
On May 12, 6:27Â*pm, pereges <[e-mail]:

I would expect the answer to be wrong by one bit or so. My gcc/3.4.5
gives -5e-16.

Mine is 4.2.3. Â*The point is I think 0 is a correct and permitted
answer. Â*It is not at all strange (to me).

This has got so surreal that I have just downloaded Pelles C. Â*If I
leave the bug in I get this output:

Es: inf Ei: 1.112194e-04 RCS: inf

I was also getting these weird results. I independently made the
initialisation change

Ah. Vital info. Without that, I thought you and the OP were
discussing the behaviour of an undefined program!

and got the results of 7.39... except for Pelles
which gave 7.08...;

>>
If I correct it by setting the missing parts of the complex numbers to
0 I get this:

Es: 7.391785e-11 Ei: 1.112194e-04 RCS: 8.351773e+00

which is exactly what gcc 4.2.3 and lcc-win32 give me. Â*It seems to be
a bug of the most ordinary nature.

My Pelles and the OP's gave 7.08....

In fact my Pelles was an old V2.9, I just downloaded the new version
and it gave the same results, namely 7.08.

I was intrigued in why 1 compiler out of 4 gave a different result,
and tracked it down to this behaviour

I am far from sure that you have. Â*Does the version you traced have
uninitialised data and does the problem remain when you add the two
extra zero initialisations? Â*If, so I will agree it looks odd, but so
far it seems to be a common all-garden bug in the code.

There's lots of other uninitialised data which may or may not be
affecting anything else. However the 7.08/7.39 discrepancy *was*
traced to these zero/near zero values.

Then the problem (or the algorithm) may be unstable, but I am not
persuaded that the compiler was wrong to produce 0 for the arithmetic
test case you posted a while back.

--
Ben.

[Bart]

On May 13, 1:58*pm, Ben Bacarisse <[e-mail]:

Bart <[e-mail]:

There's lots of other uninitialised data which may or may not be
affecting anything else. However the 7.08/7.39 discrepancy *was*
traced to these zero/near zero values.

Then the problem (or the algorithm) may be unstable, but I am not
persuaded that the compiler was wrong to produce 0 for the arithmetic
test case you posted a while back.

There was a /possibility/ of a compiler bug, but until I found one
reason for the discrepancy, we didn't know that for sure. Now it seems
Pelles was correct and the others wrong! (Because by chance Pelles
avoid the near-zero values that caused the indeterminancy later on.)

A proper fix is now up to the OP; I've already suggested care testing
values against /exactly/ 0.0 or 1.0.

--
Bartc

[Ben Bacarisse]

pereges <Br*****@gmail.comwrites:
<snip>

I had missed your post in 2nd page but I think BartC also pointed out
that bug. I replied to him on page 2.

Usenet has no pages. I am glad you have the program fixed now.

--
Ben.

[Ben Bacarisse]

Bart <[e-mail]:

On May 13, 1:58Â*pm, Ben Bacarisse <[e-mail]:

>Bart <[e-mail]:

There's lots of other uninitialised data which may or may not be
affecting anything else. However the 7.08/7.39 discrepancy *was*
traced to these zero/near zero values.

Then the problem (or the algorithm) may be unstable, but I am not
persuaded that the compiler was wrong to produce 0 for the arithmetic
test case you posted a while back.

There was a /possibility/ of a compiler bug, but until I found one
reason for the discrepancy, we didn't know that for sure. Now it seems
Pelles was correct and the others wrong!

I think that is a stretch. I know you mean that the others did not
reveal something that you feel was important, but it is going some to
get from that to the other compilers are wrong!

(Because by chance Pelles
avoid the near-zero values that caused the indeterminancy later on.)

A proper fix is now up to the OP; I've already suggested care testing
values against /exactly/ 0.0 or 1.0.

I agree that only the OP can really sort this out but in general I
think your advice is too strict. Testing for exactly *equal* to zero
is obviously problematic but deciding if a ray does or does intersect
a triangle using code like if (v < 0 || v 1) should be fine. If
including of excluding a few edge rays causes a significant change to
the results it suggests that something else is wrong.

--
Ben.

[Chris Dollin]

Richard Heathfield wrote:

Chris Dollin said:

>Richard wrote:

>>Richard Heathfield <rj*@see.sig.invalidwrites:

>>>Debuggers are over-rated by some people, and can be a huge time sink if
used flailingly.

What total and utter nonsense.

You're claiming that no-one over-rates debuggers, and that even if
used flailingly are never time-sinks. Both claims seem to be
implausible.

Good Lord, that was months ago, wasn't it? Well, days ago, anyway. Is he
the tardy one, or are you? :-)

Me. Much business porting RDF/XML IO to Jena3.

>I think your knee is jerking.

<shrugYou expected something different?

Time passes, I saw Panic Room and Mermaid Kiss; I am an optimist
again.

Remember that the above idiocy
hails from the same stable that can't distinguish between "I rarely do
such-and-such" and "I never do such-and-such", or between "I have on a few
rare occasions been able to do so-and-so" and "I can always do so-and-so".
Time spent arguing with such people is generally time wasted (which
doesn't necessarily mean it can't be fun).

If it's fun, it's not wasted. But I wasn't arguing for fun; I happened
upon the froth and wanted to call attention to its frothiness.

--
"And what you've gained is hard to quantify" - Mermaid Kiss, /Crayola Skies/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

[CBFalconer]

pereges wrote:

Ben Bacarisse <[e-mail]:

.... snip ...

>>
Did I miss the message where you explained that?

I had missed your post in 2nd page but I think BartC also pointed
out that bug. I replied to him on page 2.

page? page 2? What, if anything, does this mean? Most people are
not using the faulty google access to Usenet, which I suspect is
connected in some manner.

Mesage-ID headers are the best (but often awkward) way to identify
messages. Name and posting date/time (with full date stamp,
identifying time zone) are also usable. The easiest for all is
proper quoting.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

[CBFalconer]

Chris Dollin wrote:

Richard wrote:

>Richard Heathfield <rj*@see.sig.invalidwrites:

>>Debuggers are over-rated by some people, and can be a huge time
sink if used flailingly.

What total and utter nonsense.

You're claiming that no-one over-rates debuggers, and that even
if used flailingly are never time-sinks. Both claims seem to be
implausible.

I think this is OT, and rather useless. Very few use debuggers
unflailingly, which may well be tied into the practical problem
(today) of buying flails. I suspect their practical use is limited
to those following antique practices of flour production.

I have yet to be spammed by a flail producer.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

[pereges]

On May 13, 4:13 pm, Bart <[e-mail]:

But I've now changed a couple of things: < 0.0 to < (-EPSILON) and >
1.0 to (1+EPSILON).

*Now*, all my 4 compilers (5 including new Pelles) give the 7.08...
result.

(Whether that is right or not, I've still no idea.)

But, why should we change < 0.0 to < -EPSILON just to get consistent
results ?

Numerical accuracy is very important in my program. <0.0 is a negative
number. For example I test t < 0.0 which means if the distance that
the ray has travelled is negative, then it means the intersection is
behind the ray's origin. But taking < - EPSILON will allow a lot of
negative values of t to pass through as well.

I'm wondering if I'm doing a wrong thing by taking having a tolerance
value in my program for floating point checks. If accuracy is really
important, perhaps I should do away with such checks and compare with
exact values or may have an extremely small tolerance like 10e-20 or
something.

[pereges]

btw I changed a few things in my code to make it more efficient. In
radar.c, I got rid of gen_grid_points which was creating an array of
points i.e. pointinarray. You are creating a huge array in
initialize_radar as well(raylist array) and then you ahve two huge
arrays in the memory at the same time putting too much burden on the
system. Now, I create the points on the fly and assign it directly to
radar->raylist[i].origin which consumes less memory as I have only one
array i.e. raylist. In test.c, there is a change in formula of RCS:

RCS = 4 * PI * R ^2 * ES / Ei

where R is the average distance travelled by the scattered rays
(Rsum / Rcount)

Also, the amplitude of electrical field is now of the complex form:

a + ib so there has to be two entries for real and imaginary everytime
the user enters the amplitude.

There is also little change in the calculation of electrical field of
reflected rays as you can see in cases for r.depth == 1 and r.depth ==
2 in raytrace module. Actually the formula for electrical field is:

E(s) = E(0) * exp(-jks)

This is for direct ray when the ray is travelling from the source to
the object. E(0) is the electrical field at the source i.e. the
amplitude that you enter initially. k is the radar->wavenumber field
and s is the distance travelled by the ray.To calculate electrical
field for reflected ray:

E(s) = E(P) * RM * ( 1 / (s + 1)) * exp(-jks)

where E(P) is the electrical field incident at the point(same point
from where the reflected ray starts), is distance travelled and RM is
a reflected matrix

-1 0
0 1

Here's the code:

http://upload2.net/page/download/HaJ...ce.tar.gz.html

The code compiles and there are no errors.

For following values:

frequency: 40e+7
amplitude: 10e-4 10e-4
numberofrays: 1000

I'm getting output as:

Rsum: 25985.552124 Rcount: 25 R: 1039.422085
Es: 9.988147e-11 Ei: 3.192876e-03 RCS: 4.247141e-01

[pereges]

Here is the revised code btw:

http://upload2.net/page/download/HaJ...ce.tar.gz.html

[Ben Bacarisse]

pereges <Br*****@gmail.comwrites:

Here is the revised code btw:

http://upload2.net/page/download/HaJ...ce.tar.gz.html

For your information, you still calculate with uninitialised data. In
radar.c after calculating the number of rays, you need to run the
loops with a <= test rather than a < test. Either that or you should
not set

radar->numberofrays = (numpointsx + 1) * (numpointsy + 1);

So, remove the +1s or change the following loop to initialise the
whole array. When I do that, I get this output:

Rsum: 25983.243363 Rcount: 25 R: 1039.329735
Es: 9.497733e-11 Ei: 3.291908e-03 RCS: 3.916416e-01

I hope this helps.

--
Ben.

[pereges]

On May 16, 4:24 pm, Ben Bacarisse <[e-mail]:

For your information, you still calculate with uninitialised data. In
radar.c after calculating the number of rays, you need to run the
loops with a <= test rather than a < test. Either that or you should
not set

radar->numberofrays = (numpointsx + 1) * (numpointsy + 1);

So, remove the +1s or change the following loop to initialise the
whole array. When I do that, I get this output:

Rsum: 25983.243363 Rcount: 25 R: 1039.329735
Es: 9.497733e-11 Ei: 3.291908e-03 RCS: 3.916416e-01

True. I changed it to <= test but the output that I'm getting is
4.24e-01. I am compiling the code on linux gcc. But anyway, I'm still
in process of changing a few things. In raytrace.c I noticed there is
a lot of repetitive code which probably is not a good thing. Since you
have read my code, can you also please point out some poor practices
that I've used ?

thanks

[Bart]

On May 16, 10:16*am, pereges <[e-mail]:

On May 13, 4:13 pm, Bart <[e-mail]:

But I've now changed a couple of things: < 0.0 to < (-EPSILON) and >
1.0 to (1+EPSILON).

*Now*, all my 4 compilers (5 including new Pelles) give the 7.08...
result.

(Whether that is right or not, I've still no idea.)

But, why should we change < 0.0 to < -EPSILON just to get consistent
results ?

My interest in looking at this was solely to investigate discrepancies
in the output. This was traced to ambiguous behaviour when some values
were 'noisy' (eg. near zero but not quite zero).

Changing that zero to -epsilon was tried out of interest to see if the
program became more stable (it did).

But as Ben B pointed out, you probably had more serious issues with
your code which you've now apparently fixed.

>
Numerical accuracy is very important in my program. <0.0 is a negative
number. For example I test t < 0.0 which means if the distance that
the ray has travelled is negative, then it means the intersection is
behind the ray's origin. *But taking < - EPSILON will allow a lot of
negative values of t to pass through as well.

I'm wondering if I'm doing a wrong thing by taking having a tolerance
value in my program for floating point checks. If accuracy is really
important, perhaps I should do away with such checks and compare with
exact values or may have an extremely small tolerance like 10e-20 or
something.

This depends on many things. I personally think it's better to have
tolerances than not.

I've found these few lines in some ancient code of mine (this is not
C!):

if xt1>=(-minreal) and xt1<=(minreal+1.0) then ixstat1:=1 fi
if xt2>=(-minreal) and xt2<=(minreal+1.0) then ixstat1 ior:=2 fi

This is to do with finding if one edge crosses another. Xt1,xt2 are
0..1 if the interesection is /on/ the edge.

But because of small numerical errors, sometimes xt1/2 could be
-0.000033203 or sometimes 1.00000474, when the edges join at their
endpoints for example.

If you are summing thousands of these results, maybe it doesn't matter
if you miss a few. But if you are working with just 2 edges, the user
will get upset if the program reports 2 edges do not join when clearly
they do, within tolerance!

In your code, you are reading data specified to 6 decimal places. To
me that signifies limited accuracy. /Maybe/ you are just assuming that
these figures represent the /exact/ data, or maybe not.

--
Bartc

[Ben Bacarisse]

pereges <Br*****@gmail.comwrites:

On May 13, 4:13 pm, Bart <[e-mail]:

>But I've now changed a couple of things: < 0.0 to < (-EPSILON) and >
1.0 to (1+EPSILON).

*Now*, all my 4 compilers (5 including new Pelles) give the 7.08...
result.

(Whether that is right or not, I've still no idea.)

But, why should we change < 0.0 to < -EPSILON just to get consistent
results ?

I don't think you should. You should look on the different results as
a sign that something else is wrong. Testing for *==* zero is another
matter, but you are not doing that in the cases cited.

If your algorithm is sound, and the physical properties of the problem
are reasonable, then you should get the same result (roughly)
regardless of how you decode all the boundary cases. The program
should be coded in such a way that deciding this or that edge case one
way or the other will not have a significant effect.

Take a look at all the places where you make floating point compares.
Convince yourself that small arithmetic differences will not make any
significant contribution to the result. For example, if a few rays
fall close to a triangle edge, will deciding to include or exclude that
ray make a real difference? If so, you need to rethink the algorithm.

--
Ben.

[Bart]

On May 16, 2:27*pm, Ben Bacarisse <[e-mail]:

pereges <[e-mail]:

On May 13, 4:13 pm, Bart <[e-mail]:

But I've now changed a couple of things: < 0.0 to < (-EPSILON) and >
1.0 to (1+EPSILON).

*Now*, all my 4 compilers (5 including new Pelles) give the 7.08...
result.

(Whether that is right or not, I've still no idea.)

But, why should we change < 0.0 to < -EPSILON just to get consistent
results ?

I don't think you should. *You should look on the different results as
a sign that something else is wrong. *Testing for *==* zero is another
matter, but you are not doing that in the cases cited.

Using (v<0.0-EPSILON) (forgetting comparing with 1.0) made
intersect_triangle give nearly 800 hits instead of just over 700.
Suggesting an unhealthy clustering of dot product values around 0.0
(indicating -- I think -- a number of vectors at 90 degrees).

In this case, allowing for a small clustering near 0.0 probably won't
hurt.
-- Bartc