bug in compiler

bug in compiler

Post by Tim Chemal » Sun, 30 Nov 2003 23:26:55


I'm using BCB5 and when I compute the following I get the wrong results
============
int t = (int)log(32)/log(2);

this yields 4 instead of 5!!

However in an ActiveXForm I get 5?? What gives???

to get 5 in the first case I need to do the following

double d=log(32)/log(2);
int t = (int)d;




Regards

---------------------------------------------------------
Tim Chemaly
Internet Application Developer

Solarworks
website: www.solarworks.co.za
email: XXXX@XXXXX.COM
mobile: +27 (0) 82 729 0667
 
 
 

bug in compiler

Post by Chris Gord » Mon, 01 Dec 2003 00:06:24


log is presumably a function that returns a floating point number.

log(32)/log(2) would then return a floating point number just less than 5. I
would think that if this is converted to an integer, the result would be
just that the numbers after the decimal point would be removed, leaving 4.


Chris Gordon-Smith
London
Homepage: http://graffiti. *** .net/c.gordon-smith/
Email Address: Please see my Home Page

 
 
 

bug in compiler

Post by Ed Mulroy » Mon, 01 Dec 2003 00:12:18

You did not get an incorrect result. It did what it was coded to do.

log(32) is about 3.4657
(int) of that value truncates it to 3
3 / log(2) is about 4.3281
The conversion in the assignment to t gives 4

Tell it the correct place to apply the cast to int.

Instead of
int t = (int) log(32) / log(2);

Use
int t = (int) (log(32) / log(2));

Or remove the cast and let it do the normal conversion.

int t = log(32) / log(2);

. Ed
 
 
 

bug in compiler

Post by Tim Chemal » Mon, 01 Dec 2003 00:19:01

Hi Ed
No luck. I still get the same:
I still get 4 here

and here as well!!

In VisualC++ 6 it works fine.

Ciao
Tim
 
 
 

bug in compiler

Post by Ivan Johan » Mon, 01 Dec 2003 00:23:14


And so should it. Your (int) typecast only casts log(32) and not the
whole expression. Remove the cast or add a parenthesis:
int t = log(32)/log(2);
or
int t = (int)(log(32)/log(2));

Note that if log(32)/log(2) results in a number a little less than 5, t
will still be 4, because typecasting to int will truncate the value and
round it.
Ivan Johansen
 
 
 

bug in compiler

Post by Tim Chemal » Mon, 01 Dec 2003 00:44:22

log(32)/log(2) = log(2^5)/log(2) = 5*log(2)/log(2) = 5

It cannot be equal to a value less than 5!! How come VC++ gives me the right
results??

Ciao
Tim






I
 
 
 

bug in compiler

Post by Oscar Fuen » Mon, 01 Dec 2003 01:29:03

"Tim Chemaly" < XXXX@XXXXX.COM > writes:


Short answer: the calculation above yields something like 4.9999999999

Long (and recommended) answer:

http://www.yqcomputer.com/

Morale: floating point numbers are not real numbers.


Maybe VC++ is using a different rounding mode.

--
Oscar
 
 
 

bug in compiler

Post by Yahia El-Q » Mon, 01 Dec 2003 02:03:55

IMHO correct result - in respect with C / C++ standards - would be 4...

take a look at the _control87, _controlfp function in online help...

AFAIK VC++ and BCB always used different default settings for the numeric
coprocessor ( the floating point part of the CPU ) which leads to different
behaviour for example with rounding etc.

HTH

Yahia
 
 
 

bug in compiler

Post by Chris Gord » Mon, 01 Dec 2003 02:46:41


Or perhaps the basic calculation in VC++, before the conversion to int,
gives something like 5.00000000000001.

I see no reason to think this is a bug.
--
Chris Gordon-Smith
London
Homepage: http://graffiti. *** .net/c.gordon-smith/
Email Address: Please see my Home Page
 
 
 

bug in compiler

Post by Ed Mulroy » Mon, 01 Dec 2003 06:14:45

> In VisualC++ 6 it works fine.

To put it more correctly in VisualC++ 6 you got away with it. You said to
trust the compiler's rounding and then proffer the compiler which gave the
answer you wanted as correct.

As for what C++ Builder does, it is the same as you claim for VisualC++, one
of the TWO answers you have seen, BOTH of which are correct because you
decided that the default rounding is sufficient.

--------------------------------------------------
C:\Lookat\temp
#include <cstdio>
#include <cmath>

using std::log;
using std::printf;

int main()
{
int t = (int) log(32.0) / log(2.0);
int t2 = (int) (log(32.0) / log(2.0));
int t3 = log(32.0) / log(2.0);
double d = log(32.0) / log(2.0);

printf("%d\n%d\n%d\n%0.20f\n", t, t2, t3, d);
return 0;
}

C:\Lookat\temp
Borland C++ 5.6.4 for Win32 Copyright (c) 1993, 2002 Borland
TEMP88.CPP:
Turbo Incremental Link 5.64 Copyright (c) 1997-2002 Borland

C:\Lookat\temp
4
5
5
5.00000000000000000000

C:\Lookat\temp
--------------------------------------------------

. Ed
 
 
 

bug in compiler

Post by Clayton Ar » Mon, 01 Dec 2003 06:26:46

I performed a few simple tests in both BCB5 and BCB6 to test this.
Following is the test I used in both:

double x = log(32) / log(2);
int y = log(32) / log(2);
int z = logl(32) / logl(2);

BCB5 yielded the results:
x = 5
y = 4
z = 5

BCB6 yielded the results:
x = 5
y = 5
z = 5

On the surface it would appear that BCB5 merely calculates the division
differently. However, consider the following:

double a = log(32);
double b = log(2);
double c = a / b;
int d = a / b;

Both BCB5 and BCB6 yielded the following results:
a = 3.46573590279973
b = 0.693147180559945
c = 5
d = 5

So I would categorize this as a bug in BCB5. Something about the more
complex statement confuses BCB5.

- Clayton
 
 
 

bug in compiler

Post by Ed Mulroy » Mon, 01 Dec 2003 07:22:02

Try compiling from the command line with the -S option and looking at the
assembly file it generates.

. Ed
 
 
 

bug in compiler

Post by Ivan Johan » Mon, 01 Dec 2003 22:47:15


The FPU does not do calculations with exact numbers. Floating point
numbers does not have infinitely precision. Instead it is done similar
to this:
log(32)/log(2) = 3.46574/0.69315 = 4.99999

This is when truncated to 4.

Ivan Johansen
 
 
 

bug in compiler

Post by Tamas Demj » Wed, 03 Dec 2003 09:50:27

>>Use

In most cases it's not a good idea to convert a floating point number to
integer without rounding. I'd do this:

static_cast<int>(log(32) / log(2) + 0.5)

This will always work on every platform.

Tom
 
 
 

bug in compiler

Post by Des O'Tool » Thu, 04 Dec 2003 05:57:09


But not for negative numbers.

Des