difference found with debugger attached

[colin]

Hi,

Ive finally found what the difference is,
it seems a difference of the least significant bit
is enough to cuase a problem with part of my code,
wich determins if one point is inside a 3d model.

it works if the reference inside point does not lie exactly on
any one surface and this holds true 99.999% of the time in the debugger.

it seems sometimes my plane is ending up as X=0.9999999 in the debugger
and X=1.000000 without debugger atatched and this is enough to make
the difference of the point being exactly on the plane or not.
the inside point is used for the start of the ray.
if the start is on the plane then Ray.IntersectPlane returns null
(rather than zero.)

it also seems to make a difference when I add more code to test for certain
points wich
cuased the error last time and then print out more detailed debug info,
becuase then the point at wich it goes wrong changes.

is there something wich can be affecting the least significant bit like this
?
could it be using higher accuracy fp without the debugger attached ?
if so why does code changes wich dont alter the data at all make a
difference ?

idealy my code should not be susceptable to this so I am going to change it
anyway.
but I think I would like it to be totally deterministic,
even down to the last significant digit as im only using float.

thanks
Colin =^.^=

 

[Lasse Vågsæther Karlsen]

Hi,

Ive finally found what the difference is,
it seems a difference of the least significant bit
is enough to cuase a problem with part of my code,
wich determins if one point is inside a 3d model.

it works if the reference inside point does not lie exactly on
any one surface and this holds true 99.999% of the time in the debugger.

it seems sometimes my plane is ending up as X=0.9999999 in the debugger
and X=1.000000 without debugger atatched and this is enough to make
the difference of the point being exactly on the plane or not.
the inside point is used for the start of the ray.
if the start is on the plane then Ray.IntersectPlane returns null
(rather than zero.)

it also seems to make a difference when I add more code to test for certain
points wich
cuased the error last time and then print out more detailed debug info,
becuase then the point at wich it goes wrong changes.

is there something wich can be affecting the least significant bit like this
?
could it be using higher accuracy fp without the debugger attached ?
if so why does code changes wich dont alter the data at all make a
difference ?

idealy my code should not be susceptable to this so I am going to change it
anyway.
but I think I would like it to be totally deterministic,
even down to the last significant digit as im only using float.

thanks
Colin =^.^=

Not actually commenting on wether the debugger disturbs floating point
values or anything, but I think you will find that if you rely on
floating point being 100% accurate then you're going to be chasing bugs
and problems for the lifetime of the application.

 

[Peter Duniho]

[...]
idealy my code should not be susceptable to this so I am going to change
it
anyway.
but I think I would like it to be totally deterministic,
even down to the last significant digit as im only using float.

To expand on what Lasse wrote...

Anytime you are writing floating point code, you _cannot_ depend on exact
results unless all you're doing is copying values. Once you've done any
sort of calculation on the data, testing equality is a big no-no when
dealing with floating point, and anything that might in some way rely
equality is similarly to be avoided (such as a point being near or on a
plane).

Right now, you're noting differences in exact calculations based on the
presence of the debugger. But all sorts of other things can affect the
outcome of floating point calculations, either intended or not. One big
example is that you seem to be writing code in the context of XNA. Well,
what's a big advantage of XNA? Running cross-platform on Windows and
Xbox. Even across different installations of Windows on different
hardware, I wouldn't be surprised to occasionally come across some subtle
differences in calculations, but I suspect this would show up in even
greater degree running on the Xbox hardware.

Pete

 

[colin]

[...]
idealy my code should not be susceptable to this so I am going to change
it
anyway.
but I think I would like it to be totally deterministic,
even down to the last significant digit as im only using float.

To expand on what Lasse wrote...

Anytime you are writing floating point code, you _cannot_ depend on exact
results unless all you're doing is copying values. Once you've done any
sort of calculation on the data, testing equality is a big no-no when
dealing with floating point, and anything that might in some way rely
equality is similarly to be avoided (such as a point being near or on a
plane).

Right now, you're noting differences in exact calculations based on the
presence of the debugger. But all sorts of other things can affect the
outcome of floating point calculations, either intended or not. One big
example is that you seem to be writing code in the context of XNA. Well,
what's a big advantage of XNA? Running cross-platform on Windows and
Xbox. Even across different installations of Windows on different
hardware, I wouldn't be surprised to occasionally come across some subtle
differences in calculations, but I suspect this would show up in even
greater degree running on the Xbox hardware.

Yes I appreciate that and it was always my intention to make sure the code
didnt rely on the last digit,
but that makes it a little bit tight for float as theres only 7 dec digits
to start with.

If I simply multiply 2 floats together I expect to have the same result
whatever hardware is doing it.
however If I pass a vector to a library function wich does matrix
transformations then
I expect there to be some error due to rounding as there are many operations
involved and
the degree of error will be affected by rearanging product terms etc..

I dont intened to port it to xbox, xna is just an easy way to acces managed
directx,
it also has lots of other goodies too.
although I might revert to just plain managed directx anyway.

but I am very surprised that adding a few lines of code to just throw an
exception when a certain value is
tested for cuases yet another change ...
hmmm maybe the optimiser was able to optimise out that particular variable
for speed or better accuracy
untill I actually looked at it lol.

at least its identified some weak algorithms,
I just wish the problem was more noticble with the debugger attached rather
than not attached !
I now test for point being above surface, below surface, on the surface or
else kaput ! (like nan or something)

Colin =^.^=