# if condition should be false but isn't

This topic is 2538 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi

I've experienced a very strange case, in which an if condition turns out to be true although it should absolutely not!
The function tests if a point is inside a triangle and it works 99.99% of the time... I can also give you the values of A, B, C and Point.
The point is absolutely not inside the triangle and if you reproduce it (call the functions with the same arguments) it usually works correctly...

Should i use doubles for such a function? But it doesn't seem to have anything to do with floating point precision....?

Below are two images of the debugging (note the yellow arrow!)

##### Share on other sites
You could try putting the outcome of bc * ac - cc * ab into a variable and check what value you get in the debug environment.

##### Share on other sites
Hidden
I must admit my brain isn't firing on all cylinders this morning, but how about parenthesizing the expression?

if( (bc * ac - cc *ab) < 0 ) return false;

You could try putting the outcome of bc * ac - cc * ab into a variable and check what value you get in the debug environment.

Thanks for that bc * ac - cc * ab is exactly 0.0 when I put it into a variable. bc * ac and cc * ab were something written in scientific notation but I can't remember if very small or very big (the problem is quite difficult to reproduce because it occurs so rarely).

I have no clue what the problem could be... I mean bc and ac were normal values around 10000.0 or something....

##### Share on other sites

ab = 47583.820
ac = 51721.422
bc = 47070.406
cc = 51163.359

bc * ac = 2.4345482e+009
cc * ab = 2.4345482e+009

I've tried this just somewhere in the code with all floats and it really is like this...
the problem doesn't occur with a double for the result of bc * ac (but bc and ac can stay floats)

double bcXac = bc * ac;

this gives the correct value.

But although it works now I'm not really happy with it!
Could someone explain this behaviour, please!
And does this mean that I have to use double precision in all my collision routines?

##### Share on other sites

ab = 47583.820
ac = 51721.422
bc = 47070.406
cc = 51163.359

bc * ac = 2.4345482e+009
cc * ab = 2.4345482e+009

Let's rewrite the equation: bc * ac - cc * ab < 0 bc * ac < cc * ab
Plugging above numbers into the equation results in: 2.43... < 2.43... Or, left isn't less than right.

I've tried this just somewhere in the code with all floats and it really is like this...
the problem doesn't occur with a double for the result of bc * ac (but bc and ac can stay floats)[/quote]
It's typical accuracy problem. Switching to doubles gives you bigger range, but doesn't eliminate the issue.

Try using different testing algorithm.

##### Share on other sites
Or should I maybe use /fp:strict instead of /fp:precise?

This accuracy problem is just really bad because the application now sometimes (very rarely but still..) gets the info that the player is below a lake triangle and so he gets hurt although he is not really near to the lake...

But if it's the only solution I'll rewrite it to double precision or how do you all handle this?

##### Share on other sites
Like Antheus suggested, use a different algorithm. This is an algorithm I've used in the past, worked fine for me.

##### Share on other sites

Or should I maybe use /fp:strict instead of /fp:precise?

But if it's the only solution I'll rewrite it to double precision or how do you all handle this?

Floating point math is inaccurate. No flag or different type can change it, they merely affect particular values for which the problems occur.

This accuracy problem is just really bad because the application now sometimes (very rarely but still..) gets the info that the player is below a lake triangle and so he gets hurt although he is not really near to the lake...[/quote]

Try a different algorithm first.

##### Share on other sites
Ok I'm using a different algorithm now and it works great
Thanks

1. 1
2. 2
3. 3
4. 4
Rutin
12
5. 5

• 12
• 17
• 10
• 14
• 10
• ### Forum Statistics

• Total Topics
632660
• Total Posts
3007697
• ### Who's Online (See full list)

There are no registered users currently online

×