floating point problem

D

dis_is_eagle

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..

regards,

eric
 
I

Ian Collins

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.
 
M

MQ

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..

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?
 
G

Gordon Burditt

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
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
 
D

Default User

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
 
M

MQ

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...
 
K

Keith Thompson

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..


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.)
 
R

Richard Heathfield

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.

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.
 
A

Ancient_Hacker

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.

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>
 
A

Ancient_Hacker

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:
 
E

Eric Sosman

Ian said:
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).
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/
 
A

Ancient_Hacker

Richard said:
MQ said:


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.

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.

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.
 
R

Richard Heathfield

Ancient_Hacker said:
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>
 
K

Keith Thompson

Ancient_Hacker said:
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.
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).
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.
 
A

Ancient_Hacker

Richard said:
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? :)
 
R

Richard Heathfield

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

One might, but one doesn't need to read the IEEE 754 spec to understand why.
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.

If you check up, you'll find that I wasn't answering the OP's question. I
was making a followup comment to a followup answer.
Is the goal of this ng to polish our egos in cyberspace or to maybe
actually help answer the questions posed? :)

The goal of this newsgroup is the discussion of C programming. To answer
questions is *not* in fact the aim.

The questions asked here are rarely terribly interesting, but they often
lead to very interesting spin-off discussions about the less obvious
aspects of C and computer science. That is why some people bother to answer
them. Others like to answer them because they're nice guys who like to help
out. Sometimes the motivation is a mix of the two, and no doubt there are
other reasons why people here answer questions, but it is not the primary
purpose of the group.
 
T

Tak-Shing Chan

The questions asked here are rarely terribly interesting, but they often
lead to very interesting spin-off discussions about the less obvious
aspects of C and computer science. That is why some people bother to answer
them. Others like to answer them because they're nice guys who like to help
out. Sometimes the motivation is a mix of the two, and no doubt there are
other reasons why people here answer questions, but it is not the primary
purpose of the group.

In the above quote, Richard said ``C and computer science''
instead of just ``C''---and then he ended with ``other reasons...
not the primary purpose of the group''. This seems to suggest
that computer science is one of the primary purposes here!

Tak-Shing
 
J

Joe Wright

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..

regards,

eric
Do this instead..

#include <stdio.h>
int main(void) {
float f = 0.7;
double d = 0.7;
printf("%.16e\n", f);
printf("%.16e\n", d);
return 0;
}
 
D

Dann Corbit

Tak-Shing Chan said:
In the above quote, Richard said ``C and computer science''
instead of just ``C''---and then he ended with ``other reasons...
not the primary purpose of the group''. This seems to suggest
that computer science is one of the primary purposes here!

If it were nothing but C, then the group could be replaced by a pointer to
the ANSI/ISO C standard.

The things that really get posted here are usually mixtures of C and C
related things and things unrelated to C. The amount of tangentiality that
is allowed is probably a bit less than other groups, but that keeps the
group focused.

I recently went off on a tangent about algorithms. Now, we write algorithms
in C (and we might also say that we use C to write algorithms). We can
stray further and further from the core ideas until we are talking about
rainbows and aluminum (which is munimula, when spelled backwards).
Eventually, we must arrive at something which no longer holds any interest
for the vast majority of denizens of c.l.c.

But of course, this post is topical (along with both Richard's post and your
response) because it is a discussion of topicality, which is always
topical -- at least according to long established USENET tradition.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top