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.  
Share this Question
P: n/a

"Peter Ammon" <ge******@splintermac.com> 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  
P: n/a

Peter Pichler wrote: "Peter Ammon" <ge******@splintermac.com> 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  
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/  
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  
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/  
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  
P: n/a

On Mon, 16 Feb 2004 19:12:57 GMT, pete <pf*****@mindspring.com> 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://JKTechnology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/Cfaq/top.html
comp.lang.c++ http://www.parashift.com/c++faqlite/
alt.comp.lang.learn.cc++ http://www.contrib.andrew.cmu.edu/~a...FAQacllc.html  
P: n/a

pete <pf*****@mindspring.com> 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  
P: n/a

Jack Klein wrote: On Mon, 16 Feb 2004 19:12:57 GMT, pete <pf*****@mindspring.com> 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  
P: n/a

On Mon, 16 Feb 2004 08:38:37 0000, "Peter Pichler" <pi*****@pobox.sk>
wrote: "Peter Ammon" <ge******@splintermac.com> wrote in message news:J6*****************@newssvr25.news.prodigy.co m...
<snip> 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   This discussion thread is closed Replies have been disabled for this discussion.   Question stats  viewed: 1229
 replies: 10
 date asked: Nov 14 '05
