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.