Debug works, Release doesn't?

[lspecht]

I came across this in my MFC app and simplified the code into this console app for this example. When I compile and run the following code in Debug mode, it gives the correct answer for i, (10). When I compile and run it in Release mode, it gives the wrong answer for i, (11). Anyone know why?

#include <iostream>
using namespace std;

void main(){
    int i;
    double yTest;

    i=0;
    yTest = 100000000.;
    while (yTest-.01 > 0.){
        yTest /= 10.;
        i++;
    }

    cout<<i<<endl;
}

VS 2003 .Net Version 7.1.3088

[Lindley]

Release mode frequently uses "fast math" computations which are faster but slightly less accurate. Of course, expecting something like this to be completely accurate seems rather dubious anyway.....floats dinnae work like that.

Any math that can be "broken" by a change in compile settings does not exhibit numerical stability, which is a highly desirable property for computer programs.

[VictorN]

I've just tested this code in VS2008 and result is the same for both Release and Debug: it is 10

[lspecht]

So where is the instability in my code? I totally expected this to work no matter how it was compiled? How should it be written?

[lspecht]

Thanks, Victor. I was afraid of that. Guess I'll have to write some hack code to deal with it until I can upgrade.

[VictorN]

Interesting! VC++6.0 gave me the same results as your VS 2003:
10 - for Debug
11 - for Release

[Paul McKenzie]

So where is the instability in my code?

0.1 is not an exact binary floating point number. Therefore your loop is ill-formed, as there is no guarantee how many times it will execute.

The bottom line is that loop counters should be done in integer, not floating point. If you know you must loop 10,000 times, then specifiy that explicitly using integer.

Regards,

Paul McKenzie

[Paul McKenzie]

Read the message here, and go to the link concerning using floating point math as loop controllers.

http://www.codeguru.com/forum/showpo...52&postcount=3

Regards,

Paul McKenzie

[lspecht]

The problem is I don't know how many times the loop needs to run. It will likely be different every time. Your point should be taken care of by the fact that I'm using > and not an exact equality to exit the loop.

[lspecht]

Paul,

I have a better understanding now that I read the post you referenced. Thanks for the information. I'll have to think of a solution that will work no matter which compiler option I use.

[VictorN]

OK, let's simplify this test:

#include <iostream>
#include "tchar.h"
using namespace std;

int _tmain(int argc, TCHAR* argv[])
{
    double yTest;
    yTest = 0.1;
    yTest /= 10.;
	if(yTest > .01)
		printf("yTest > .01\n");
	else
		printf("yTest <= .01\n");

    return 0;
}

The results:
VC++6.0, Debug:

yTest <= .01

VC++6.0, Release:

yTest > .01

VS2008, Debug:

yTest <= .01

VS2008, Release:

yTest <= .01

[Paul McKenzie]

Paul,

I have a better understanding now that I read the post you referenced. Thanks for the information. I'll have to think of a solution that will work no matter which compiler option I use.

Unless I'm totally off, you can try the following as a hint:

The number of times you loop will be based on the log10 of yTest.

Regards,

Paul McKenzie

[Paul McKenzie]

OK, let's simplify this test:

#include <iostream>
#include "tchar.h"
using namespace std;

int _tmain(int argc, TCHAR* argv[])
{
    double yTest;
    yTest = 0.1;
    yTest /= 10.;
	if(yTest > .01)
		printf("yTest > .01\n");
	else
		printf("yTest <= .01\n");

    return 0;
}

The results:
VC++6.0, Debug:

yTest <= .01

VC++6.0, Release:

yTest > .01

VS2008, Debug:

yTest <= .01

VS2008, Release:

yTest <= .01

The problem is that 0.1 has no exact binary representation, and dividing that number by 10 incurs more round-off error. How much round-off error depends on compiler, compiler options, etc.

If you started yTest at 0.5 and then divided by 2, you should see that the results are the same, regardless of compiler, compiler options, etc.

Regards,

Paul McKenzie

[VictorN]

The problem is that 0.1 has no exact binary representation, and dividing that number by 10 incurs more round-off error.

I agree!
What I couldn't understand is why:
either binary representation of 0.1 differs for Debug and Release
or FP-divide operation is performed differently for Debug and Release.

[Paul McKenzie]

I agree!
What I couldn't understand is why:
either binary representation of 0.1 differs for Debug and Release
or FP-divide operation is performed differently for Debug and Release.

Probably the latter. I remember that different compilers do different things with the floating point unit, even things that seem as simple as a division.

A look at the assembly code would answer the question of what really happens during the division.

Regards,

Paul McKenzie