#### Archived

This topic is now archived and is closed to further replies.

# Basic if statement not working when using exact figures, but range works.

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

## Recommended Posts

I am a little lost on this problem. I have found a solution to it, but I am still totally stumped on why my first method doesn't work. So here's the situation. I have a rather complex if statement, and I've found the problem in it lies in this section: if(/* bla bla bla*/ puzzlePoints[point].psi->yOffset == -4.0f) { // do whatever } the yOffset variable is a float, and when I debug my app, it is set to -4.00000. Yet, my if statement fails. I know this is the problem because I replaced that with: if(*/bla bla bla*/ puzzlePoints[point].psi->yOffset < -3.99999f && puzzlePoints[point].psi->yOffset > -4.00001f) Using that range, the if statement works fine. I could use the range and be ok, but I am curious as to why the exact == doesn't work. I have also tried writing the -4.0f as -4, -4.0, -4.00000, (float)-4.0, (float)-4. None of those worked either. Any ideas? Thanks all. --Vic-- The future of 2D game development: Flat Red Ball [edited by - Roof Top Pew Wee on July 27, 2003 12:15:00 PM]

##### Share on other sites
You should rarely, if ever, compare floating point numbers for equality. The format is prone to numerical error. The range you used is one proper solution; otherwise, use something like this:

if(abs(number -4.0) < 0.00001)

How appropriate. You fight like a cow.

##### Share on other sites
Your problem lies within float itself.

A float is usually 32 bits large. So is an int on 32 bit processors. With 32 bits you can represent 2^32 different states. Each of those states is uniquely mapped to one numerical value with ints. So an int can represent 4294967296 numbers (be it all positive or half negative and half positive). A float, however, can represent a much greater amount of numbers simply because it stores information on digits on both sides of the decimal dot. That means the data has to be organized in a different manner. It''s sorta compressed. This compression, however, causes it to lose accuracy. That''s the reason why you _have to_ check floating-point data types against some tolerance, unless you write a wrapper that automates this, of course (no big deal).
Thus, it''s very possible to assign 2.0f to a float and have a conditional check immediately afterwards return that it''s not 2.0f.

As a side note, floating-point data types lose accuracy greatly when you have large values on the left side of the decimal dot. So, if you need great precision you must keep the absolute value as small as possible.

##### Share on other sites
If the value is between -4.000004999 and -3.999995, the debugger will display it as 4.00000, but that doesn''t mean that "puzzlePoints[point].psi->yOffset == 4.0f" is true.

##### Share on other sites
Bless this site! And everyone that replied. Not only did that fix that problem, but other problems I had related to that function. Thanks everyone!!!

--Vic--

The future of 2D game development:
Flat Red Ball

##### Share on other sites
here''s a fun little piece of code that sort of illustrates the inaccuracies of floating point notation:
#include<stdio.h>main(){     for( float x = 33554430; x <= 33554440; x++ )        printf("%f\n", x);    return 0;}

1. 1
2. 2
3. 3
Rutin
18
4. 4
5. 5
JoeJ
13

• 14
• 10
• 23
• 9
• 49
• ### Forum Statistics

• Total Topics
632639
• Total Posts
3007587
• ### Who's Online (See full list)

There are no registered users currently online

×