Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > problem with output of the program on different OS

Reply
Thread Tools

problem with output of the program on different OS

 
 
pereges
Guest
Posts: n/a
 
      05-16-2008

Here is the revised code btw:

http://upload2.net/page/download/HaJ...ce.tar.gz.html
 
Reply With Quote
 
 
 
 
Ben Bacarisse
Guest
Posts: n/a
 
      05-16-2008
pereges <(E-Mail Removed)> writes:

> 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.
 
Reply With Quote
 
 
 
 
pereges
Guest
Posts: n/a
 
      05-16-2008
On May 16, 4:24 pm, Ben Bacarisse <(E-Mail Removed)> wrote:

> 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

 
Reply With Quote
 
Bart
Guest
Posts: n/a
 
      05-16-2008
On May 16, 10:16*am, pereges <(E-Mail Removed)> wrote:
> On May 13, 4:13 pm, Bart <(E-Mail Removed)> wrote:
>
> > 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
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      05-16-2008
pereges <(E-Mail Removed)> writes:

> On May 13, 4:13 pm, Bart <(E-Mail Removed)> wrote:
>
>
>> 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.
 
Reply With Quote
 
Bart
Guest
Posts: n/a
 
      05-16-2008
On May 16, 2:27*pm, Ben Bacarisse <(E-Mail Removed)> wrote:
> pereges <(E-Mail Removed)> writes:
> > On May 13, 4:13 pm, Bart <(E-Mail Removed)> wrote:

>
> >> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
os.popen output different from native shell output nickname Python 7 08-26-2009 02:18 PM
Simple MD5 Hash - Different output on different OS Smurff C Programming 10 11-21-2008 04:27 PM
Javascript code same but output is different on different browsers pradeep Javascript 3 06-07-2007 07:52 PM
list of html code same but output is different on different browsers pradeep HTML 3 06-07-2007 05:54 PM
write a single line C program whose output is the program itself Puneet C Programming 16 03-20-2005 08:15 AM



Advertisments