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

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

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

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

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

No luck. I still get the same:

I still get 4 here

and here as well!!

In VisualC++ 6 it works fine.

Ciao

Tim

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

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

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

results??

Ciao

Tim

I

"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

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

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

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

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

> 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

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

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

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

Try compiling from the command line with the -S option and looking at the

assembly file it generates.

. Ed

assembly file it generates.

. Ed

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

>>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

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

1. Internal compiler error - vc compiler bug or faulty code?

2. Solution (was: Internal compiler error - vc compiler bug or faulty code?)

3. BUG: Visual Basic Internal compiler error (related to the known bug)

4. [BUG][VB.NET] Compiler bug with attributes

5. [tao-bugs] Tao_Idl Compiler : 'Possible' bug in includes forPOA_CORBA::Policy Skeleton?

7. [tao-bugs] Tao_Idl Compiler : 'Possible' bug in includes for POA_CORBA::Policy Skeleton?

8. [tao-bugs] Tao_Idl Compiler : 'Possible' bug in forward refs in valuetype?

9. Upgrading Add-Ins to Excel 2007 -- Compatibility & Bugs

10. IE7B2 Bug Report - Start failure after second reboot after ins

11. Bug in Excel handling VBA/VBScript installation of Add-Ins

12. BUG - Project add-ins and Form DataGrid

13. Can I get native code add-ins when I development the add-ins using C#?

14. Can only remove add-ins but cannot add add-ins in Outlook 2003 anymore

15. Visio Tools? Add-Ins, Plug-Ins, etc.

15 post • Page:**1** of **2**