double rant/question ( and a smallish dll q. )

[Maximilien]

( I'm having a bad week ..., so this might simply be a rant instead of a question ) I know that I cannot be certain that a value stored in a double will ever be internally represented like it is on paper, or as I type it in a text box and convert the string to a double. for example for the value 2.5 I can either have ( not sure about the "real" decimal precision, so YMMV ) d = 2.50000000001; or d = 2.49999999999; wich is acceptable if the desired precision is small. now, the question is, and it's what is bugging me. Is there a way to ensure better precision, or to round up to a precisison ? also, can there be an issue when using the same DLL with debug or release version ? I have two different results with the same input when I build in debug or in release; I don't have access to the dll source code. Thanks. Max.

---

Maximilien Lincourt Your Head A Splode - Strong Bad

[SunKnight0]

I don't think there is a way to ensure precision on the way the value is stored, unless the desired precision is small enough to convert it to an integer (so you would store 2.5 as 250 and know that you have to divide by 100 to get the actaul value), but you can implement the desired precision in your code checking, assuming the variance in the way the value is stored is less than the desired precision. For example, if you are testing monetary values and you only need to be precise to 0.01 then equality is checked by something like fabs(a-b)<0.01 which is roughly equivalent to a==b. When checking for limits and you would ideally want, for example a<=100, just use a<100.01, etc.

[Achim Klein]

Hi, if you want to round up to a precision, try this one: // Rounds a double to the nearest multiple of the passed seed. double round(double Num, double Seed) { // get rational factor double fac = Num / Seed; // get natural factor fac = (fac < 0) ? (static_cast(fac - 0.5)) : (static_cast(fac + 0.5)); // return multiple return fac * Seed; }

[peterchen]

reason: the FPU internally uses a higher precision. The "last digits" depend on how long the optimizer keeps a value in the FPU before writing it back to memory. Builds are not even guaranteed to be "stable", i.e. the code generated may differ from build to build. Always use an eps comparison ( fabs(a-b) < eps, where eps must be sufficiently small compared to the OOM of a and b)

---

Pandoras Gift #44: Hope. The one that keeps you on suffering.
aber.. "Wie gesagt, der Scheiss is' Therapie"
boost your code || Fold With Us! || sighist | doxygen