double

[brekehan]

I ran across some code that is initializing a double:

double x = 1e-5;

Does the standard dictate the compiler to interpret that as 0.00001?
or is the above representation error prone?

,
Chris

 

[Gianni Mariani]

I ran across some code that is initializing a double:

double x = 1e-5;

Does the standard dictate the compiler to interpret that as 0.00001?

It does.

or is the above representation error prone?

I've yet to see an error with this.

 

[brekehan]

Well, I am experiencing some very odd behavior where stepping through
my code, a comparison between doubles is resulting in true when it
should be false.

inline bool LessThan(double high, double low)
{
double error = 1e-5;
return (high - low) > error;
}


LessThan(0.0, 0);
// returns true!!!
//(0.0 - 0.0) > 0.00001 should evaluate to false.

There is a rumor around the office that this is some gcc or processor
specific artifact where doubles have a differant precision in
registers vs memory or something along those lines. I falsely assumed
the representation of the double being assigned was at fault.

Has anyone come across problems comparing two doubles before?

 

[AnonMail2005]

Well, I am experiencing some very odd behavior where stepping through
my code, a comparison between doubles is resulting in true when it
should be false.

inline bool LessThan(double high, double low)
{
double error = 1e-5;
return (high - low) > error;

}

LessThan(0.0, 0);
// returns true!!!
//(0.0 - 0.0) > 0.00001 should evaluate to false.

There is a rumor around the office that this is some gcc or processor
specific artifact where doubles have a differant precision in
registers vs memory or something along those lines. I falsely assumed
the representation of the double being assigned was at fault.

Has anyone come across problems comparing two doubles before?

As long as you use a tolerance you should be fine.

But you should use something like this:
std::fabs (high - low) > tolerance; // std::fabs is in <cmath> btw

hth

 

[Gianni Mariani]

brekehan wrote:
....

Has anyone come across problems comparing two doubles before?

all the time.

The code below returns false for me.

inline bool LessThan(double high, double low)
{
double error = 1e-5;
return (high - low) > error;
}

#include <iostream>

int main()
{
std::cout << LessThan(0.0, 0);
}

..... I can't reproduce your problem.

 

[Guest]

Well, I am experiencing some very odd behavior where stepping through
my code, a comparison between doubles is resulting in true when it
should be false.

inline bool LessThan(double high, double low)
{
double error = 1e-5;
return (high - low) > error;
}


LessThan(0.0, 0);
// returns true!!!
//(0.0 - 0.0) > 0.00001 should evaluate to false.

It works for me with VC++.

There is a rumor around the office that this is some gcc or processor
specific artifact where doubles have a differant precision in
registers vs memory or something along those lines. I falsely assumed
the representation of the double being assigned was at fault.

Has anyone come across problems comparing two doubles before?

When directly comparing doubles one should expect problems, but with
code like yours, never.

 

[brekehan]

brekehan wrote:

...


all the time.

The code below returns false for me.

inline bool LessThan(double high, double low)
{
double error = 1e-5;
return (high - low) > error;

}

#include <iostream>

int main()
{
std::cout << LessThan(0.0, 0);

}

.... I can't reproduce your problem.

Most likely because of some compiler flag we are using combined with
the version of gcc, the processor, and what instructions it is
actually using I've been told we are using "double precision". I am
still trying to decypher all these compiler flags.

 

[AnonMail2005]

As long as you use a tolerance you should be fine.

But you should use something like this:
std::fabs (high - low) > tolerance; // std::fabs is in <cmath> btw

hth- Hide quoted text -

- Show quoted text -

That should be a <.

 

[brekehan]

It works for me with VC++.



When directly comparing doubles one should expect problems, but with
code like yours, never.

I wonder if it is some combination of compiler version, processor,
flags, etc.
The forementioned code was compiled on gcc 3.3.1
There seems to be a mess of compiler flags too one if which I am told
is "double precision"
I'd give more info if it was my code and my environment :/ I'll keep
searching around.

 

[LR]

http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.17

LR

 

[Christopher Pisz]

http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.17

LR

That faq says why it isn't working, but doesn't give much insite into how to
get it to work. Yes, my mind is blown. I always depended on my compiler
being smart enough to know how to give me the result of a floating point
comparison accurately. If one value is differant than another depending on
its storage, I would think the compiled code would make sure they are stored
the same way when comparing...guess not. Can't point the finger though. I
haven't exactly written my own compiler or created any floating point
hardware. The remaining question is, how to safely compare two doubles with
all of the comparison operators and how to safely perform arithmetic on
floating point numbers and get the desired results? I figured that was the
entire purpose if this comparison function existing in the first
place...since we can't rely on a built in < , >, or == operator.

 

[LR]

That faq says why it isn't working, but doesn't give much insite into how to
get it to work. Yes, my mind is blown. I always depended on my compiler
being smart enough to know how to give me the result of a floating point
comparison accurately. If one value is differant than another depending on
its storage, I would think the compiled code would make sure they are stored
the same way when comparing...guess not. Can't point the finger though. I
haven't exactly written my own compiler or created any floating point
hardware. The remaining question is, how to safely compare two doubles with
all of the comparison operators and how to safely perform arithmetic on
floating point numbers and get the desired results? I figured that was the
entire purpose if this comparison function existing in the first
place...since we can't rely on a built in < , >, or == operator.

Sorry. Responded too fast.

I went back and took a look again.

The code the OP posted was:

inline bool LessThan(double high, double low) {
double error = 1e-5;
return (high - low) > error;
}

.....
const bool r = LessThan(0.0, 0);

// r ends up as true, but
//(0.0 - 0.0) > 0.00001 should evaluate to false.

I wonder if somewhere else in the code there is a function like this:

inline bool LessThan(double high, int low) {
return true;
}

LR

 

[Christopher Pisz]

Sorry. Responded too fast.

I went back and took a look again.

The code the OP posted was:

inline bool LessThan(double high, double low) {
double error = 1e-5;
return (high - low) > error;
}

....
const bool r = LessThan(0.0, 0);

// r ends up as true, but
//(0.0 - 0.0) > 0.00001 should evaluate to false.

I wonder if somewhere else in the code there is a function like this:

inline bool LessThan(double high, int low) {
return true;
}

LR

Nope, that isn't it, because stepping through the debugger it goes into the
function posted.

 

[Stuart Redmann]

> Well, I am experiencing some very odd behavior where stepping through
> my code, a comparison between doubles is resulting in true when it
> should be false.
>
> inline bool LessThan(double high, double low)
> {
> double error = 1e-5;
> return (high - low) > error;
> }
>
>
> LessThan(0.0, 0);
> // returns true!!!
> //(0.0 - 0.0) > 0.00001 should evaluate to false.
>
There is a rumor around the office that this is some gcc or processor
specific artifact where doubles have a differant precision in
registers vs memory or something along those lines. I falsely assumed
the representation of the double being assigned was at fault.

See http://www.intel.com/support/performancetools/c/sb/cs-007691.htm.
As for the case you state above, this issue doesn't matter (the precision is
high enough for the comparison under Linux as well as Windows apps).

It would be nice to know which compiler + flags you are using (possibly some HW
description might help, too). As this question would then become a bit off-topic
here, you might consider re-stating your question in a newsgroup dedicated to
your compiler/HW.

Regards,
Stuart

 

[Tim Slattery]

I ran across some code that is initializing a double:

double x = 1e-5;

Does the standard dictate the compiler to interpret that as 0.00001?
or is the above representation error prone?

1e-.5 means 1 times ten to the -5 power, which works out to .00001.
You then are converting it to a double precision floating point.
Floating point numbers are approximations! Even if you have enough
precision to store all the digits (which you do here) you have to
remember that not all decimal fractions can be exactly represented by
binary fractions. And floating point numbers are nearly always stored
internally as binary fractions. So what you get is not exactly what
you see.

 

[LR]

Nope, that isn't it, because stepping through the debugger it goes into the
function posted.

I'm bewildered.

Can you take that function and put it into a small test program and see
what happens? Just,

int main() {
const bool r = LessThan(0.,0);
std::cout << r << std::endl;
}

Or can you rewrite the function a little bit? Something like:

bool LessThan(const double high, const double low) {
static const double error = 1e-5;
const double diff = high - low;
const bool result = diff > error;
return result;
}

Or maybe put some trace in?

Or can you write something like this to see what happens?

int main() {
const bool r = 0.0 > 1e-5;
std::cout << r << std::endl;
}

LR

 

[James Kanze]

1e-.5 means 1 times ten to the -5 power, which works out to .00001.
You then are converting it to a double precision floating point.
Floating point numbers are approximations!

More strictly stated, floating point numbers are not capable of
representing all possible real values. (Strictly speaking, they
aren't an approximation in themselves---each floating point
value represents one single value very exactly. The
"approximation" occurs when you think in terms of real numbers.)

Even if you have enough
precision to store all the digits (which you do here) you have to
remember that not all decimal fractions can be exactly represented by
binary fractions. And floating point numbers are nearly always stored
internally as binary fractions.

So what you get is not exactly what you see.

The standard says very little about the requirements when
converting decimal to floating point, but I would consider any
implementation which converted 1e-5 and 0.00001 to different
floating point values to be very deficient.

 

[brekehan]

I'm bewildered.

Can you take that function and put it into a small test program and see
what happens? Just,

int main() {
const bool r = LessThan(0.,0);
std::cout << r << std::endl;

}

Or can you rewrite the function a little bit? Something like:

bool LessThan(const double high, const double low) {
static const double error = 1e-5;
const double diff = high - low;
const bool result = diff > error;
return result;

}

Or maybe put some trace in?

Or can you write something like this to see what happens?

int main() {
const bool r = 0.0 > 1e-5;
std::cout << r << std::endl;

}

LR- Hide quoted text -

- Show quoted text -

Unfortunatly, since this code was at work and in my work environment,
it has since been zapped into a state where the original situation
cannot be reproduced. I tryed some isolated test cases and they all
seem to work. I can only assume there was some logic error somewhere
and keep an eye open for it to appear again. In the meanwhile, I did
some good reading on floating point comparisons.

 

[Markus Moll]

Hi

Well, I am experiencing some very odd behavior where stepping through
my code, a comparison between doubles is resulting in true when it
should be false.

inline bool LessThan(double high, double low)
{
double error = 1e-5;
return (high - low) > error;
}


LessThan(0.0, 0);
// returns true!!!
//(0.0 - 0.0) > 0.00001 should evaluate to false.

Honestly, I don't believe that (or maybe you are using a very broken
compiler... but then you should have notices before)

This is one of the rare cases where the subtraction should actually be
exact. Are you sure you are calling LessThan with constants 0.0 and 0? Or
do you call it with some arguments that look like 0.0 and 0? (E.g. when
printed)

There is a rumor around the office that this is some gcc or processor
specific artifact where doubles have a differant precision in
registers vs memory or something along those lines. I falsely assumed
the representation of the double being assigned was at fault.

Still, the exact value 0 should be representable in whatever format the
compiler chooses.

Has anyone come across problems comparing two doubles before?

Yes, but certainly not this one.

Maybe your stack is corrupted? (check for a missing return statement or
something like that...)

Markus