[Solved] Different results in debug and release modes

[andry_gasy]

Thank you for the answer. I tried it but no change (as expected).

[zweistein]

In release:
@
int Z;
float conc,min,max,step;
@
those are not initialized with 0, as it is in debugmode. So initialize them with 0 in the constructor of your class.

[andry_gasy]

Thank you but before these instructions, I initialized already all these members.
The problem seems to come from the object but I don't know where (I'm not so experienced).
I tried to use vector of myclass and resize it when needed but the results are the same.
@
vector<myclass> Cons;
Cons.resize(nbCons);
@

[andry_gasy]

So I just took the first loop to calculate nbSim to see what's wrong. I found out that if I put a qDebug() << c inside the loop, the results are the same in debug and release modes. I think it's related to float precision or what?? I really have no idea. Any help please.

[mlong]

Kind of off the subject, but if you have the code:
@
for (float c=Cons[i].min;c<=Cons[i].max;c+=Cons[i].step)
nbSim++;
@
whose sole purpose is to calculate the number of steps needed, why not just use
@
int nbSim = ((Cons[i].max - Cons[i].min) / Cons[i].step) + 1;
@

Furthermore, why not make it a utility method in your class:
@
class myclass
{
public:
myclass() {
Z = 0;
conc = min = max = step = 0.0f;
}

int numSteps() {
return ((Cons[i].max - Cons[i].min) / Cons[i].step) + 1;
}

int Z;
float conc,min,max,step;
};
@

Also, consider using Qt's containers (QList, QVector, etc.) in place of a stdc++ vector or an array. Then you could use
@
QList<myclass> Cons;
...

foreach (myclass item, Cons)
{
... do something with each one ...
}
@

[andry_gasy]

Thanks for the hints. I began like that to calculate nbSim. Then seeing the difference in the results, I thought doing exactly the same thing may solve it, which was not the case.
I have tried the following simple example:
@
float min=1.8541,max=20.54335,step=0.00014521;

int i=0;
for (float f=min;f<=max;f+=step)
{        
    i++;
}

@

and actually the results are DIFFERENT in debug (128814) and release mode (128705).
So I think my problem comes really from this floating point behavior. Can someone tell me how to deal with this? Is it a bug or is it normal?

[mlong]

I don't think it's a bug, per se, as I'm sure that there are different floating-point handling procedures in place when you're in debug mode. In release mode, the compiler may optimize things slightly different.

Since floating point precision is always an issue, it doesn't seem to me to be out of the realm of normal operations.

You might try using doubles instead of floats for more precision.

[koahnig]

Your release mode value is closer to what you would obtain by building the difference and divide by step.

However, as mlong pointed out, why are you doing this?

BTW float has typically about 6-7 digits when expressed as 4 byte. So you are right at the limit, if your compiler does not use a double internally.

The difference might be a result from internal casting from double to float and vis versa. If you really want to do what you do, try to do it at least with double, which shall be 8 byte in most compilers.

[andry_gasy]

Thank you all for your reply. Using double did in fact SOLVE the problem. I was though skeptical as in my real work, I don't have so "big" numbers. I have an example below where I have 9 objects Cons. I give here the min, max and step values for all 9 objects

@MIN:
3.239
7.16
6.855
0.979
5.77
6.37
6.415
6.47
6.74@

@MAX:
9.716
21.48
20.57
2.937
17.31
19.11
19.24
19.41
20.22@

@STEP:
0.3239
0.716
0.6855
0.0979
0.577
0.637
0.6415
0.647
0.674@

Again, thanks a lot for your contributions.

[koahnig]

Good to see that your issue has been solved.

The whole issue is completely depending on the HW, OS, compiler and their options. A general answer was not really possible on your initial input.

Compilations in debug mode and release mode will typically provide different answers for problems similar to yours. Even for double numbers you may see issues when approaching situations where you are getting close to their typically 16(?) significant digits. Some of the numeric processing is optimized by the HW for Intel's math co-processors. They convert 8 byte doubles to 10 bytes doubles for carrying out the math. However, by standard most compilers are handling doubles only with 8 bytes. This requires a couple transformations forth and back again, when numbers are loaded and stored again. In most cases this is of no issue.

For you it is likely that the 4 byte float is transformed to a 10 byte double for calculations and transformed back to 4 byte. Optimizing is often trying, depending on the actual compile settings, to avoid those translations forth back. You have to dig quite deeply with the details of HW, OS, ... for getting a definite answer. However, the results you have provided do back those assumptions.

Finally you might want to mark your thread with [Solved] in the title.

[andry_gasy]

How do I mark it as solved?

[koahnig]

Either you found already or a moderator has done for you.

For next time in case it was a moderator. You should be able to edit any of your entries. Just at the right of your text below your avatar is an edit link. If you do in the opening post, you can edit the title line.