435,082 Members | 2,135 Online
Need help? Post your question and get tips & solutions from a community of 435,082 IT Pros & Developers. It's quick & easy.

# Requirements of floating point comparisons

 P: n/a I'm fuzzy on exactly what I can depend on when doing floating point comparisons. I know that calculated values can differ, e.g. I'm not guaranteed that 1. + 2. == 3. What about comparisons with literals? float f=3.; int v = f==3.; is v guaranteed to be one? What about situations involving conversions between floats and doubles? int v = 3.f == 3.; How about for values calculated from strings? int v = strtod("3.0", NULL)==3.; Any other situations I should know about? Thanks for any advice, -Peter -- Pull out a splinter to reply. Nov 14 '05 #1
10 Replies

 P: n/a "Peter Ammon" wrote in message news:J6*****************@newssvr25.news.prodigy.co m... I'm fuzzy on exactly what I can depend on when doing floating point comparisons. I know that calculated values can differ, e.g. I'm not guaranteed that 1. + 2. == 3. Right. Although in this case, you probably *will* get a match. What about comparisons with literals? No difference. Why do you think there should be any? float f=3.; int v = f==3.; is v guaranteed to be one? In this particular case, very likely. In general, no. What about situations involving conversions between floats and doubles? Same thing. int v = 3.f == 3.; Is this a typo? How about for values calculated from strings? int v = strtod("3.0", NULL)==3.; The same in a different shade of mauve. Any other situations I should know about? You may find that a and b may not compare equal in the following case: float a = 1.0/10.0, b = 0.1; Peter Nov 14 '05 #2

 P: n/a Peter Pichler wrote: "Peter Ammon" wrote in message news:J6*****************@newssvr25.news.prodigy.co m... I'm fuzzy on exactly what I can depend on when doing floating point comparisons. I know that calculated values can differ, e.g. I'm not guaranteed that 1. + 2. == 3. Right. Although in this case, you probably *will* get a match. What about comparisons with literals? No difference. Why do you think there should be any? float f=3.; int v = f==3.; is v guaranteed to be one? In this particular case, very likely. In general, no. What about situations involving conversions between floats and doubles? Same thing. int v = 3.f == 3.; Is this a typo? How about for values calculated from strings? int v = strtod("3.0", NULL)==3.; The same in a different shade of mauve. Any other situations I should know about? You may find that a and b may not compare equal in the following case: float a = 1.0/10.0, b = 0.1; But, the OP seemed more interested in assignment operations rather than arithmetic operations. I would assume that for double f = 0.1; that (f == 0.1) was true, regardless of whether 0.1 could be represented exactly as a double. My reasoning is that even if 0.1 can't be represented exactly, then whatever it's representation is, will be the same for both the constant and the object. -- pete Nov 14 '05 #3

 P: n/a In article <40***********@mindspring.com> pf*****@mindspring.com writes: .... I would assume that for double f = 0.1; that (f == 0.1) was true, regardless of whether 0.1 could be represented exactly as a double. My reasoning is that even if 0.1 can't be represented exactly, then whatever it's representation is, will be the same for both the constant and the object. Perhaps. The constant 0.1 can be kept in extended precision. -- dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131 home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/ Nov 14 '05 #4

 P: n/a Dik T. Winter wrote: In article <40***********@mindspring.com> pf*****@mindspring.com writes: ... > I would assume that for > double f = 0.1; > that > (f == 0.1) > was true, > regardless of whether 0.1 could be represented exactly as a double. > My reasoning is that even if 0.1 can't be represented exactly, > then whatever it's representation is, > will be the same for both the constant and the object. Perhaps. The constant 0.1 can be kept in extended precision. If an object of type double has been assigned the value of a constant of type double, then should the value of the object compare equal to the value of the constant ? I think it should, always. -- pete Nov 14 '05 #5

 P: n/a In article <40***********@mindspring.com> pf*****@mindspring.com writes: Dik T. Winter wrote: In article <40***********@mindspring.com> pf*****@mindspring.com writes: ... > I would assume that for > double f = 0.1; > that > (f == 0.1) > was true, > regardless of whether 0.1 could be represented exactly as a double. > My reasoning is that even if 0.1 can't be represented exactly, > then whatever it's representation is, > will be the same for both the constant and the object. Perhaps. The constant 0.1 can be kept in extended precision. If an object of type double has been assigned the value of a constant of type double, then should the value of the object compare equal to the value of the constant ? I think it should, always. Why? The assignment to the double can lead to loss of precision when the constant is held in extended precision (and as far as I know that is allowed by the standard). -- dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131 home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/ Nov 14 '05 #6

 P: n/a Dik T. Winter wrote: In article <40***********@mindspring.com> pf*****@mindspring.com writes: > Dik T. Winter wrote: > > > > In article <40***********@mindspring.com> pf*****@mindspring.com writes: > > ... > > > I would assume that for > > > double f = 0.1; > > > that > > > (f == 0.1) > > > was true, > > > regardless of whether 0.1 could be represented exactly as a double. > > > My reasoning is that even if 0.1 can't be represented exactly, > > > then whatever it's representation is, > > > will be the same for both the constant and the object. > > > > Perhaps. The constant 0.1 can be kept in extended precision. > > If an object of type double has been assigned the value > of a constant of type double, then should the value > of the object compare equal to the value of the constant ? > I think it should, always. Why? The assignment to the double can lead to loss of precision when the constant is held in extended precision (and as far as I know that is allowed by the standard). Constants have the same types as objects. Representations are specified by type. -- pete Nov 14 '05 #7

 P: n/a On Mon, 16 Feb 2004 19:12:57 GMT, pete wrote in comp.lang.c: Dik T. Winter wrote: In article <40***********@mindspring.com> pf*****@mindspring.com writes: > Dik T. Winter wrote: > > > > In article <40***********@mindspring.com> pf*****@mindspring.com writes: > > ... > > > I would assume that for > > > double f = 0.1; > > > that > > > (f == 0.1) > > > was true, > > > regardless of whether 0.1 could be represented exactly as a double. > > > My reasoning is that even if 0.1 can't be represented exactly, > > > then whatever it's representation is, > > > will be the same for both the constant and the object. > > > > Perhaps. The constant 0.1 can be kept in extended precision. > > If an object of type double has been assigned the value > of a constant of type double, then should the value > of the object compare equal to the value of the constant ? > I think it should, always. Why? The assignment to the double can lead to loss of precision when the constant is held in extended precision (and as far as I know that is allowed by the standard). Constants have the same types as objects. Representations are specified by type. That's all very well in theory, but actually quite rarely observed in practice. Regardless of what you think comparing a double initialized from a floating point literal, and an identical floating point literal at some other time can fail in many cases on many compilers. -- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html comp.lang.c++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c++ http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html Nov 14 '05 #8

 P: n/a pete wrote in message news:<40***********@mindspring.com>... Dik T. Winter wrote: In article <40***********@mindspring.com> pf*****@mindspring.com writes: ... > I would assume that for > double f = 0.1; > that > (f == 0.1) > was true, > regardless of whether 0.1 could be represented exactly as a double. > My reasoning is that even if 0.1 can't be represented exactly, > then whatever it's representation is, > will be the same for both the constant and the object. Perhaps. The constant 0.1 can be kept in extended precision. If an object of type double has been assigned the value of a constant of type double, then should the value of the object compare equal to the value of the constant ? I think it should, always. Look up the thread "Are Floating Point Constants "constant?" (back in 1998) for more than you want to know about this topic. While the standard allows some leeway in the value which will be used given a floating point constant (e.g. 0.1) the question is "must the choice be consistent". There was no consensus (personally, I don't think the standard does mandate consistency). In practice, I would not depend on the implementation to get this right, even if the requirement was clear. - William Hughes Nov 14 '05 #9

 P: n/a Jack Klein wrote: On Mon, 16 Feb 2004 19:12:57 GMT, pete wrote in comp.lang.c: Dik T. Winter wrote: In article <40***********@mindspring.com> pf*****@mindspring.com writes: > Dik T. Winter wrote: > > > > In article <40***********@mindspring.com> pf*****@mindspring.com writes: > > ... > > > I would assume that for > > > double f = 0.1; > > > that > > > (f == 0.1) > > > was true, > > > regardless of whether 0.1 could be represented exactly as a double. > > > My reasoning is that even if 0.1 can't be represented exactly, > > > then whatever it's representation is, > > > will be the same for both the constant and the object. > > > > Perhaps. The constant 0.1 can be kept in extended precision. > > If an object of type double has been assigned the value > of a constant of type double, then should the value > of the object compare equal to the value of the constant ? > I think it should, always. Why? The assignment to the double can lead to loss of precision when the constant is held in extended precision (and as far as I know that is allowed by the standard). Constants have the same types as objects. Representations are specified by type. That's all very well in theory, but actually quite rarely observed in practice. Regardless of what you think comparing a double initialized from a floating point literal, and an identical floating point literal at some other time can fail in many cases on many compilers. Thank you. I'll check out the 1998 "Are Floating Point Constants "constant?" thread, suggested by William Hughes. -- pete Nov 14 '05 #10

 P: n/a On Mon, 16 Feb 2004 08:38:37 -0000, "Peter Pichler" wrote: "Peter Ammon" wrote in message news:J6*****************@newssvr25.news.prodigy.co m... What about situations involving conversions between floats and doubles? Same thing. int v = 3.f == 3.; Is this a typo? No. 3.f is a float (single) constant; 3. is a double constant. That illustrates exactly his question "between floats and doubles". Although it might not be exactly the best illustration, since this computation can and probably will be done at compile time; plus 3. is (well) within the range that will be exactly represented, and exactly computed, on any remotely plausible FP implementation. Something like _Bool foo (double x) { return x = 7654321.f; } .... foo (7654321.) ... would be a better example. (concur with the rest) - David.Thompson1 at worldnet.att.net Nov 14 '05 #11

### This discussion thread is closed

Replies have been disabled for this discussion.