Hello,

Some months ago I found a bug (I think) in all Borland compilers I tried.

Consider this function :

int Bug()
{
double a;
int c;

a=75.0;
c=a*(3000.0/2500.0);

return c;
}

You can expect than this function returns 90, but it returns 89!
If you replace "c=a*(3000.0/2500.0);" for "c=a*((float)3000.0/(float)2500.0);" or for "c=a*3000.0/2500.0;" then it returns 90 correctly. Also if you declare c as float works well too.

I have tried this in TC 3.0, Borland C++ 5.02 and Builder 4. With Microsoft Visual C++ 6.0 doesn't happen. I had reported this to Borland on Feb. 25th and haven't received response yet! :-(

Can anyone try this in Builder 5?

This again proves the value of separating the sheep and the goats. Mixing types 'should normally be safe' as the compilers will jump through hoops to accomodate our coding 'sins', coverting types, etc.  :)  This is an interesting one, though most of these 'error animals' do an implicit float or double to int conversion to hilight the 'fault'. MS had similar problems a few years back with Excel calculations (which one assumes was written in MS C++), giving divide errors on integer values!

I had seen a similar effect. I got different results running a program in the IDE and as standalone. I think that is a problem of the run time Library.

hnd
hasso55@yahoo.com

Instead of getting 90 , you are getting 89 . it is because it you look at the storage method . The double stores it as 80.999999 something depending upon the system.
I have a code , just run it. And find the answer .
#include <stdio.h>
int main() {
    float a = 3.7;
    if (a == 3.7)
        printf("A is 3.7\n");
    else
        printf("Not 3.7 ");
    return 0;
}

Thanx
Siddhartha Singh
ssingh@aztecsoft.com

Siddhartha Singh
siddhu_singh@hotmail.com

Is more than a storage method problem. The following example return 90.

int Bug()
{
double a,b;
int c;

a=75.0;
b=a*(3000.0/2500.0);
c=b;

return c;
}

Th only diference is the usage of 'b'.

Ferran Casarramona

then it could be a bug. But amazingly, when b is assigned to an int c. The value changes to 90. Is it??? Did you check thru breakpoints that when the value is assigned to b then it has 89  and when b is assigned to c the value of c is 90. If this is happening then we must inform Borland.
But this is just amazing.

Siddhartha Singh
siddhu_singh@hotmail.com

No, 'b' is assigned 90. I have inspected the assembler code and I think I have found the solution:

 Borland and Microsoft compilers generate the same code :

c=a*(3000.0/2500.0);
0040144B DD 05 28 51 41 00   fld        qword ptr[00415128]     ; constant = 1.2 (note than in binary have not an                                                                                                                                                                                       ; exact representation)
00401451 DC 4D 80                fmul      qword ptr [a]                ; Multiply
00401454 E8 57 0B 00 00       call        _ftol (00401fb0)            ; Conversion to int
00401459 89 85 74 FF FF FF  mov       dword ptr [c],eax          ; assigning to int.

but after multiply, Borland gives a result of 89.99999999999... and Microsoft give 90.0000000000. The reason for this is than Borland works with more precision, (the Precision Control (PC) bits of the FPU "Control Word" is marked to use 64 bits precision by Borland programs and 53 bit precision by Microsoft programs), so the result is not rounded to 90 after the multiply operation. (I had found this technical details about i486 processors and compatibles at http://www.x86.org/intel.doc/486manuals.htm )

I still don't understand why when assigning to a double the result is rounded to 90, but not if is assigned directly to a int. I suppose than the FPU work internally with more precision than "double" type and no rounded operations are made.

Now the question is : Is best use high precision inside FPU than in memory as Borland does? Or is better use the same precision to get the same results if we use memory variables or FPU registers?

Ferran Casarramona

Ferran,

    It will depend on what you are looking for. If you are just going to round to the nearest integer, then less decimal precision is best. If you need to carry the decimal out then the reverse is best. It is up to the programmer to make these decisions and the programmer should be aware of how to squeeze the best out of the compiler.

    As a side note, I notice in the June issue of C/C++ Users Journal that there is an article by Pete Becker on Floating Point Basics. I haven't read the article yet so I can't say if it applies here but it may explain some things.

James P. Cottingham

International Veneer Co., Inc.
All opinions are mine alone and do not necessarily reflect those of my employer.