fractions becoming integers

This is a discussion on fractions becoming integers within the C++ Programming forums, part of the General Programming Boards category; does anyone have a problem where the compiler automatically evaluates fractions to integers? im using ms vc++ 98 and i ...

  1. #1
    mustang benny bennyandthejets's Avatar
    Join Date
    Jul 2002
    Posts
    1,401

    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?
    benforbes@optusnet.com.au
    Microsoft Visual Studio .NET 2003 Enterprise Architect
    Windows XP Pro

    Code Tags
    Programming FAQ
    Tutorials

  2. #2
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    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. #3
    mustang benny bennyandthejets's Avatar
    Join Date
    Jul 2002
    Posts
    1,401
    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?
    benforbes@optusnet.com.au
    Microsoft Visual Studio .NET 2003 Enterprise Architect
    Windows XP Pro

    Code Tags
    Programming FAQ
    Tutorials

  4. #4
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    Sure.
    Code:
    answer = 2/5.0;

  5. #5
    Registered User
    Join Date
    Jul 2002
    Posts
    273
    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. #6
    Registered User
    Join Date
    Apr 2002
    Posts
    362
    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
    "When the only tool you own is a hammer, every problem begins to resemble a nail." Abraham Maslow

  7. #7
    Registered User
    Join Date
    Jul 2002
    Posts
    273
    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. #8
    Registered User
    Join Date
    Apr 2002
    Posts
    362
    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
    "When the only tool you own is a hammer, every problem begins to resemble a nail." Abraham Maslow

  9. #9
    Registered User raimo's Avatar
    Join Date
    Jun 2002
    Posts
    107
    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. #10
    Registered User The Dog's Avatar
    Join Date
    May 2002
    Location
    Cape Town
    Posts
    788
    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. #11
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,796
    >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
    My best code is written with the delete key.

  12. #12
    Registered User
    Join Date
    Apr 2002
    Posts
    362
    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
    "When the only tool you own is a hammer, every problem begins to resemble a nail." Abraham Maslow

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Link List math
    By t014y in forum C Programming
    Replies: 17
    Last Post: 02-20-2009, 05:55 PM
  2. Assignment HELP!!
    By cprogrammer22 in forum C Programming
    Replies: 35
    Last Post: 01-24-2009, 01:24 PM
  3. Integers into array.
    By livestrng in forum C Programming
    Replies: 10
    Last Post: 10-29-2008, 11:35 PM
  4. simplfying fractions
    By treenef in forum C++ Programming
    Replies: 4
    Last Post: 04-02-2005, 08:52 AM
  5. Replies: 6
    Last Post: 08-04-2003, 10:57 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21