Requirements of floating point comparisons

[Peter Ammon]

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

 

[Peter Pichler]

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

 

[pete]

Right. Although in this case, you probably *will* get a match.


No difference. Why do you think there should be any?


In this particular case, very likely. In general, no.


Same thing.


Is this a typo?


The same in a different shade of mauve.


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.

 

[Dik T. Winter]

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

 

[pete]

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.

 

[Dik T. Winter]

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

 

[pete]

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.

 

[Jack Klein]

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.

 

[William Hughes]

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

 

[pete]

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.

 

[Dave Thompson]

Same thing.


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