float problem with gcvt(), precision, and Pentium 4??

[Anonymous]

Assume the following quick code sample:

void AddFloatText(LPSTR a,LPSTR b,LPSTR sum)
{
     double  an,bn;

     an = atof(a);                  // convert number string to float
     bn = atof(b);                  // convert number string to float
     an += bn;                       // add them
     (void) gcvt(an,16,sum);    // convert back to string
}

Seems reasonable, right?  Well, I am getting some unexpected results using Visual C++ 6.0 with latest service packs and libraries on a P4 running Windows XP.

For example, when I try to add  "4905.69" + "4905.69" with the string size set to 16 as above, I get a result of "9811.379999999999" instead of "9811.38."   If I set the size to 15 or lower, I get the correct answer. ?!

Similarly, this happens with other string quantities with decimal points to greater or lesser degree depending on how large I set the string size.   If I set the string size to be larger, like 20 or 30, I get many more errors in my datastream.  

The problem does not appear to be with the atof() function.  In the above case using atof, an=4905.6900000000 and bn=4905.6900000000 (according to the debug windows in VC++).  So, where is the precision error coming from?

Is this a floating point math bug in the Pentium 4?  Am I making some other glaring error in my use of these stdclib calls?  I can't imagine what it would be...

Your help is appreciated.

Thanks.

[Anonymous]

I should add that the double value before using gcvt() is also correct, according to the debug window.

It is 9811.3800000000.  The problem occurs when I try and use gcvt() to go from double back to string and end up with 9811.379999999999.

Thanks...

[Anonymous]

I had a few moments to debug and it looks like the IEEE overflow flag is being set.  Is there a limit for these functions of 16 digits?

[Anonymous]

Well...for those like me who have never messed around with the floating point library routines and double data types, here is the answer:

The "double" data type only has a precision of 15 digits.  So, anything more than that will cause an overflow.  I didn't really think about the data type precision when I made the call.  I knew my data had much less precision and I thought it was just being 0-padded based on the supplied buffer size after the calculation on the significant digits.  The solution is not to specify a buffer bigger than 15 characters, since the library routines will attempt to calculate that precision and overflow.

Now you know and so do I.  Just double trouble.