Thread: fractions becoming integers

does anyone have a problem where the compiler automatically evaluates fractions to integers? im using ms vc++ 98 and i never noticed this before today. say i have the code:

Code:

double answer;
answer=2/5;
cout << answer << endl;

when it runs, it rounds the number down to zero.
but when i do this:

Code:

double answer;
answer=(double)2/5;
cout << answer << endl;

it works fine. why do i have to use type casting just to store a fraction? could it just be my compiler?

that 2f/5f business didn't work at all, but 2.0/5.0 did.

it seems like a bit of a drag though, i dont want to put .0 on whenever i want fractions! isn't there another solution?

Just as "fun and exciting" when you find that floating-point math returns other-than-expected results.

I recommend researching representational error for those who haven't, yet, encountered this idiosyncrasy.

Integer math is, almost always, the way to go where accuracy is concerned.

(Has anyone ever gone over his/her checking account to find an inexplicable $0.11 discrepancy where no discrepancy should exist? Multiply that by thousands and, "Wow!").

-Skipper

bennyandthejets,

I rather skipped over your question (sorry) and don't know that any of us really gave you an appropriate response. (Good info, mind you, just not a "good" answer.)

The "division" operator (/) will always perform its function on the right operand so, when we speak of fractions, they will be in the form of decimal values. The arithmetic operation will, in fact, take place, much as you may not care for it to do so.

Since the right operand (the value, or expression to the right of the assignment operator) in your example involves two integer values, the result will be an integer, i.e. the manitissa of the arithmetic operation. Any decimal value of the operation is truncated. Hence, the "zero" result.

Suppose, now, that 'answer' had been declared/defined* as a 'float'. (Think you'll get tricky, eh?.) You'd still wind up with '0'. The mantissa would still be zero, but no coercion will take place. Why? The left operand (the variable to the left of the "assignment operator") does not implicitly invoke "type casting". It takes what we feed it. (Are we having fun yet? )

Now, you don't like adding the .0, right? Declare your numerator and denominator as 'floats' from the start. Don't make explicit assignments, but use variable names. In this way, the compiler will coerce 2 to 2.0 and 5 to 5.0, thus alleviating your burden. You, and your "users", will be free to input 'integer' values without fear of causing the program to go "South" on you.

* While the "definition" of variables is well-covered in any good C++ reference, bear in mind that any time the compiler allocates memory for a variable value, that value is "defined".

That is, 'int x;' is no less a "definition" than 'int x = 7;' is.

(I'll plant the seed. You take it from here.)

-Skipper

>why do i have to use type casting just to store a fraction? could it just be my compiler?
It's not your compiler, the result of an integral operation is an integer. So 2 / 5 is .4, but integers don't support that precision and it is changed to 0. Then you assign that 0 to a double variable and it becomes 0.0. To maintain the precision you must cast the values or use floating-point constants so that the epression doesn't result in an integer value.

-Prelude

Prelude,

Were you bored?

This thread is a little "beneath" you, isn't it?

(A compliment, by the way. I've studied your stuff, if you'll excuse the vernacular.)

Actually, I've yet to determine why, exactly, the left operand fails to coerce the result of an operation, even when it's declared of the same "type".

(Not compiler-centric. Borland and MSVC++ behave the same way. I've tested both.)

Ahhh... these little things....

-Skipper