floating point problem

FAQ

Memberlist

Usergroups

Profile

Preferences

· nixdoc.net

· man pages

· Linux HOWTOs

· FreeBSD Tips

· Forums

Forum index » Programming » C

floating point problem

Page 1 of 3 [34 Posts]

View previous topic :: View next topic
Goto page: 1, 2, 3 Next

Author

Message

Ian
*nix forums Guru

Joined: 16 Aug 2005
Posts: 1615

Posted: Thu Jul 20, 2006 7:39 am Post subject: Note

Re: floating point problem

dis_is_eagle@yahoo.com wrote:

Quote:

hi....i have encountered strange problem regarding floating point
comparison...the problem is...

main()
{
float a=0.7;
if(0.7 > a)
printf("hi");
else
printf("hello");
}

i think the answer should have hello...but strangely it is hi....but
for a=0.8 the answer is hello...again for a=0.9 the answer is hi....the
program is run on a linux system....if anybody explains this problem it
will be very helpful...thanx in advance...bye..

Welcome to the joyous, imprecise world of floating point. Consult the

group's FAQ and all will be explained.

--
Ian Collins.

michaelquinlivan@gmail.co
*nix forums beginner

Joined: 03 Jul 2006
Posts: 24

Posted: Thu Jul 20, 2006 7:40 am Post subject: Note

Re: floating point problem

dis_is_eagle@yahoo.com wrote:

Quote:

I don't get the same results. It does say "hi" for the first one, but
is "hello" for the second and third cases. Is this what you meant?

Gordon Burditt
*nix forums Guru

Joined: 02 Mar 2005
Posts: 773

Posted: Thu Jul 20, 2006 7:42 am Post subject: Note

Re: floating point problem

Quote:

hi....i have encountered strange problem regarding floating point
comparison...the problem is...

There is no exact representation for most non-integer values in
binary floating point. The closest possible value may be above or
below the exact mathematical value.

0.7 as double:
Before: 0.699999999999999844568776552478084340691566467285156250000000
Value: 0.699999999999999955591079014993738383054733276367187500000000
After: 0.700000000000000066613381477509392425417900085449218750000000

0.7 as float:
Before: 0.699999928474426269531250000000000000000000000000000000000000
Value: 0.699999988079071044921875000000000000000000000000000000000000
After: 0.700000047683715820312500000000000000000000000000000000000000

0.8 as double:
Before: 0.799999999999999933386618522490607574582099914550781250000000
Value: 0.800000000000000044408920985006261616945266723632812500000000
After: 0.800000000000000155431223447521915659308433532714843750000000

0.8 as float:
Before: 0.799999952316284179687500000000000000000000000000000000000000
Value: 0.800000011920928955078125000000000000000000000000000000000000
After: 0.800000071525573730468750000000000000000000000000000000000000

Quote:

main()
{
float a=0.7;
if(0.7 > a)
printf("hi");
else
printf("hello");
}

i think the answer should have hello...but strangely it is hi....but
for a=0.8 the answer is hello...again for a=0.9 the answer is hi....the
program is run on a linux system....if anybody explains this problem it
will be very helpful...thanx in advance...bye..

Gordon L. Burditt

Default User
*nix forums Guru

Joined: 21 Feb 2005
Posts: 1159

Posted: Thu Jul 20, 2006 7:42 am Post subject: Note

Re: floating point problem

dis_is_eagle@yahoo.com wrote:

Quote:

hi....i have encountered strange problem regarding floating point
comparison...the problem is...

main()
{
float a=0.7;
if(0.7 > a)
printf("hi");
else
printf("hello");
}

i think the answer should have hello...but strangely it is hi....but
for a=0.8 the answer is hello...again for a=0.9 the answer is
hi....the program is run on a linux system....if anybody explains
this problem it will be very helpful...thanx in advance...bye..

http://c-faq.com/fp/strangefp.html

Brian

michaelquinlivan@gmail.co
*nix forums beginner

Joined: 03 Jul 2006
Posts: 24

Posted: Thu Jul 20, 2006 7:43 am Post subject: Re: floating point problem

And yes, as Ian describes above, floating point numbers are not represented exactly. Have a look at the IEEE 754 standard for FP numbers to see why...

Keith Thompson
*nix forums Guru

Joined: 28 Feb 2005
Posts: 5173

Posted: Thu Jul 20, 2006 8:02 am Post subject: Note

Re: floating point problem

dis_is_eagle@yahoo.com writes:

Quote:

The comp.lang.c FAQ is at <http://www.c-faq.com/>. You've asked
something very close to question 14.1.

(Incidentally, the ellipsis, "...", doesn't mean what you think it
means.)

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

neutron*star
*nix forums Guru

Joined: 21 Feb 2005
Posts: 2039

Posted: Thu Jul 20, 2006 8:12 am Post subject: Note

Re: floating point problem

MQ said:

Quote:

And yes, as Ian describes above, floating point numbers are not
represented exactly. Have a look at the IEEE 754 standard for FP
numbers to see why...

No need. It's perfectly obvious why.

Let's say you've got a 32-bit float (not terribly unlikely). There are 2^32
possible bit combinations. That's 4294967296 different numbers.

FLT_MAX is 1E37. That's 10000000000000000000000000000000000000.

So for every single bit combination, there are 2328306436538696289062500000
*integers* that need to be represented by it, let alone infinitely many
real numbers.

You can't fit infinitely many infinitely long bit sequences into a finite
number of bits without a little lossitude.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

Ancient_Hacker
*nix forums beginner

Joined: 31 May 2006
Posts: 42

Posted: Thu Jul 20, 2006 11:14 am Post subject: Note

Re: floating point problem

Keith Thompson wrote:

Quote:

The comp.lang.c FAQ is at <http://www.c-faq.com/>. You've asked
something very close to question 14.1.

Not even remotely correct. Question 14.1 has to do with printf
floating point output, which is explicitly rounded by the
floating-point output routine to the nearest DECIMAL digit.

The original poster's question has to do with floating-point
comparisons. A whole differnt ball of wax. Or tar.

The correct answer is more involved: The constant "0.7" when first
seen by the compiler is evaluated to the precision of a double. When
you store this constant into your variable, the compiler silently
truncates it to the width of a float.

Then when you compare the variable to another "0.7", the compiler sees
things diffeerently-- it sees a double (the constant) being compared to
a float (the variable). In order to not lose any precison, the
compiler then (silently) converts the float variable to a double and
does a DOUBLE comparison. Here's the code geneated by Watcom C for
the relevant section of code:

mov dword ptr -0x8[ebp],0x3f333333 // store 3f333333
into the float variable
fld dword ptr -0x8[ebp] // push the dword (4-byte)
variable onto the fp stack
fcomp qword ptr L$3 // compare top of stack with
qword (8 byte) constant

Segment: CONST DWORD USE32 00000011 bytes
L$3:
66 66 66 66 66 66 E6 3F // 0.7 as a DOUBLE
(64-bit) constant

... as you can see, the float contant 0.7 is 0xf333333, while as a
double, it goes on for another 4 bytes. When compared, they're not
equal.

Now if you'd used the statement: if( 0.7f < a ) the compiler
would see TWO floats and do a FLOAT comparison, which is much more
likely to show equality. This is the relevant code:
0050 D9 05 14 00 00 00 fld dword ptr L$8
0056 D8 5D F8 fcomp dword ptr -0x8[ebp]

Notice it's pushing a dword and comparing it with a dword, so there's a
much better chance of equality reigning.

<soap>
But IN GENERAL, you should NEVER expect two floating-point quantities
to be ever equal or non-equal. The chances are vanishingly small.
Some more rational languages, such as APL, take this into account and
you can set the amount of "fuzz" you want to allow for equality tests.
In the other languages, you need to write some function to do
approximate equality tests, something like this if you decide being
within one part per million is close enough:

boolean AreWithinOnePPM( double a, b ) { double delta;
delta = fabs( a - b );
return fabs( a ) / 1.0E-6 < delta ;
}
</SOAP>

Ancient_Hacker
*nix forums beginner

Joined: 31 May 2006
Posts: 42

Posted: Thu Jul 20, 2006 12:07 pm Post subject: Note

Re: floating point problem

A few more points:

I got the comparison direction backwards AND goofed on the constant's
type, it doesnt change the result, but for clarity it should be:

Quote:

boolean AreWithinOnePPM( double a, b ) { double delta;
delta = fabs( a - b );
return delta < fabs( a ) / 1.0D-6 ;
}

Eric Sosman
*nix forums Guru

Joined: 21 Feb 2005
Posts: 1246

Posted: Thu Jul 20, 2006 12:08 pm Post subject: Note

Re: floating point problem

Ian Collins wrote:

Quote:

dis_is_eagle@yahoo.com wrote:

hi....i have encountered strange problem regarding floating point
comparison...the problem is...

main()
{
float a=0.7;
if(0.7 > a)
printf("hi");
else
printf("hello");
}

i think the answer should have hello...but strangely it is hi....but
for a=0.8 the answer is hello...again for a=0.9 the answer is hi....the
program is run on a linux system....if anybody explains this problem it
will be very helpful...thanx in advance...bye..

Welcome to the joyous, imprecise world of floating point.

Well, sort of, but that's not really the problem here.
The real issue in this program is that `float' and `double'
have different precisions (on most systems).

Quote:

Consult the
group's FAQ and all will be explained.

A link would be helpful: One place to find the FAQ is

http://c-faq.com/

--
Eric Sosman
esosman@acm-dot-org.invalid

Ancient_Hacker
*nix forums beginner

Joined: 31 May 2006
Posts: 42

Posted: Thu Jul 20, 2006 12:28 pm Post subject: Note

Re: floating point problem

Richard Heathfield wrote:

Quote:

MQ said:

And yes, as Ian describes above, floating point numbers are not
represented exactly. Have a look at the IEEE 754 standard for FP
numbers to see why...

No need. It's perfectly obvious why.

Let's say you've got a 32-bit float (not terribly unlikely). There are 2^32
possible bit combinations. That's 4294967296 different numbers.

Um, no. Floating-point numbers are almost always "normalized", which
on some architectures means means you never have leading binary zeroes;
on other Fp formats, an extra leading "1" bit is assumed, but never
seen, so you have an extra bit, but then you *do* have leading and
significant zeroes. Also in many formats there are reserved exponent
values, for instance an exponent of all zeroes or all 1's often implies
an exact zero, no matter what the mantissa says. Other places there
are reserved exponents and mantissas for flagging indefinite, inexact,
unset, or infiite values.

Quote:

FLT_MAX is 1E37. That's 10000000000000000000000000000000000000.

Very few machines have decimal floating-point numbers, and those that
do are unlikely to have a binary (2^127 or whatnot) exponent limit. .
The exact FLT_MAX is likely to be different on a binary machine.

Quote:

You can't fit infinitely many infinitely long bit sequences into a finite
number of bits without a little lossitude.

The poor OP question was a bit more de-facto-- "why do two uses of 0.7
work differently". See other posts for answer.

Dik T. Winter
*nix forums Guru

Joined: 23 Feb 2005
Posts: 327

Posted: Thu Jul 20, 2006 12:49 pm Post subject: Note

Re: floating point problem

In article <1153398532.876406.288820@i42g2000cwa.googlegroups.com> "Ancient_Hacker" <grg2@comcast.net> writes:

Quote:

Richard Heathfield wrote:
MQ said:

And yes, as Ian describes above, floating point numbers are not
represented exactly. Have a look at the IEEE 754 standard for FP
numbers to see why...

No need. It's perfectly obvious why.

Let's say you've got a 32-bit float (not terribly unlikely). There are 2^32
possible bit combinations. That's 4294967296 different numbers.

Um, no.

Let's have 32-bit floats. So there are 4294967296 different bit patterns.
That means that at most so many numbers can be represented.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

neutron*star
*nix forums Guru

Joined: 21 Feb 2005
Posts: 2039

Posted: Thu Jul 20, 2006 1:06 pm Post subject: Note

Re: floating point problem

Ancient_Hacker said:

Quote:

Richard Heathfield wrote:
MQ said:

And yes, as Ian describes above, floating point numbers are not
represented exactly. Have a look at the IEEE 754 standard for FP
numbers to see why...

No need. It's perfectly obvious why.

Let's say you've got a 32-bit float (not terribly unlikely). There are
2^32 possible bit combinations. That's 4294967296 different numbers.

Um, no. Floating-point numbers are almost always "normalized", which
on some architectures means means you never have leading binary zeroes;

Um, that is totally and utterly irrelevant to my point, which is that with
32 bits you only have 2^32 bit patterns so you can only represent 2^32
different values, and this is true no matter what those values are. If you
have N bits, you have 2^N possible values. No matter how large N is (within
the constraints of the real world), there will never be enough bits to
represent all possible numbers. Therefore, it is inevitable that some
numbers can only be represented approximately. QED.

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

Keith Thompson
*nix forums Guru

Joined: 28 Feb 2005
Posts: 5173

Posted: Thu Jul 20, 2006 3:32 pm Post subject: Note

Re: floating point problem

"Ancient_Hacker" <grg2@comcast.net> writes:

Quote:

Keith Thompson wrote:
The comp.lang.c FAQ is at <http://www.c-faq.com/>. You've asked
something very close to question 14.1.

Not even remotely correct. Question 14.1 has to do with printf
floating point output, which is explicitly rounded by the
floating-point output routine to the nearest DECIMAL digit.

Yes, it is remotely correct. Cool

}

Question 14.1 is really only peripherally about printf.

Q: When I set a float variable to, say, 3.1, why is printf
printing it as 3.0999999?

A: Most computers use base 2 for floating-point numbers as well as
for integers, and just as for base 10, not all fractions are
representable exactly in base 2. It's well-known that in base
10, a fraction like 1/3 = 0.333333... repeats infinitely. It
turns out that in base 2, one tenth is also an
infinitely-repeating fraction (0.0001100110011...), so exact
decimal fractions such as 3.1 cannot be represented exactly in
binary. Depending on how carefully your compiler's
binary/decimal conversion routines (such as those used by
printf) have been written, you may see discrepancies when
numbers not exactly representable in base 2 are assigned or
read in and then printed (i.e. converted from base 10 to base 2
and back again). [footnote] See also question 14.6.

Both 14.1 and the OP's question are basically about the fact that
floating-point is inexact, and values like 3.1 and 0.7 cannot be
represented exactly.

Quote:

The original poster's question has to do with floating-point
comparisons. A whole differnt ball of wax. Or tar.

The correct answer is more involved: The constant "0.7" when first
seen by the compiler is evaluated to the precision of a double. When
you store this constant into your variable, the compiler silently
truncates it to the width of a float.

You're right, the OP's situation is also affected by float vs. double
issues. I should have picked up on that. In fact, a better answer
would have been to suggest that the OP should read all of section 14
of the FAQ (though I'm not sure it addresses this specific issue).

Quote:

Then when you compare the variable to another "0.7", the compiler sees
things diffeerently-- it sees a double (the constant) being compared to
a float (the variable). In order to not lose any precison, the
compiler then (silently) converts the float variable to a double and
does a DOUBLE comparison. Here's the code geneated by Watcom C for
the relevant section of code:
[snip]

IMHO, the issue can be explained more clearly without resorting to
assembly language.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Ancient_Hacker
*nix forums beginner

Joined: 31 May 2006
Posts: 42

Posted: Thu Jul 20, 2006 3:33 pm Post subject: Note

Re: floating point problem

Richard Heathfield wrote:

Quote:

Um, that is totally and utterly irrelevant to my point, which is that with
32 bits you only have 2^32 bit patterns so you can only represent 2^32
different values,

One might suspect most programmers are aware it's impossible to
represent an infinite number of distinct states in a computer.

This poor sod was just wondering why 0.7 didnt seem to equal 0.7, and
probably wanting to learn why and how to avoid this in the future.

So that comment was obvious, inaccurate and generally unhelpful toward
the goal of answering the posers question.

Is the goal of this ng to polish our egos in cyberspace or to maybe
actually help answer the questions posed? Smile

Google

Display posts from previous:

Page 1 of 3 [34 Posts]

Goto page: 1, 2, 3 Next
View previous topic :: View next topic

The time now is Thu Dec 04, 2008 2:55 am | All times are GMT

Forum index » Programming » C

Jump to:

Topic		Author	Forum	Replies	Last Post
Similar Topics
	Unknown in header problem -SOLVED-	Light Speed	Postfix	0	Thu Jul 03, 2008 10:40 am
	problem with sending mail	nuxia	Postfix	0	Mon Apr 21, 2008 3:58 am
	Postfix 2.3.8 Virtual problem	Blotto	Postfix	0	Fri Apr 04, 2008 6:11 am
	Postfix sending problem for local domain remote email	monkey_magix	Postfix	0	Mon Sep 10, 2007 10:17 am
	bounce problem	murkis	Postfix	0	Sun Oct 08, 2006 3:45 pm

Computer Forums | Adverse Credit Remortgage | Debt Consolidation | Loans | Magazine Subscription

Other DeniX Solutions sites: Unix/Linux blog | electronics forum | medicine forum | science forum |

[ Time: 5.9804s ][ Queries: 16 (5.8022s) ][ GZIP on - Debug on ]