# Thread: fractions becoming integers

1. ## 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;
cout << answer << endl;```
when it runs, it rounds the number down to zero.
but when i do this:

Code:
```double answer;
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?

2. No way, you don't have to type cast! Just do this
Code:
`double answer = 2.0/5.0;`
This works too.
Code:
`answer = 2f/5f;`

3. 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?

4. Sure.
Code:
`answer = 2/5.0;`

5. the reason is that integer math is much faster. 2/5 has to be seen as 2 divided by 5 rather than 2 fifths because it gives you a FAST default. not sure why 2f / 5f didn't work but casting and decimals will work just fine normally. It's fun and exciting when integer math is unexpected though isn't it?

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

7. skipper is right. integer math is the way to go where you can figure out how to do it. floating point math is NOT precise. It is a close rounding to the number.

There are usually ways to figure out how. In your example, the reason you need .4 is obscured so it's tough to say how that could change.

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

9. Ha, you don't need 2.0/5.0: 2/5. is enough(that's what I use when calculating with Python)

But, we all know that integers rule. You can always write your own routine to floating point numbers using integer types.

But for something like: "How much money do I have?" floats go fine.

10. Just keep in mind that any expression will result to the type of the
variable with the highest comprehension.

But here's what happens :
If you say
Code:
```  float var;
var = 'a' + 15234.44;```
The value var will have the decimals stored in it because 'a' is
promoted to a float.

In this case
Code:
```  int var;
var = 'a' + 15234.44;```
The value 15234.44 is demoted to an int.

The casting is done implicitly.

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

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

Popular pages Recent additions