Thread: conversion from double to float - loss of data

  1. #1
    Registered User
    Join Date
    Mar 2008
    Posts
    7

    conversion from double to float - loss of data

    I have an assignment for programming that is actually pretty easy, if it were not for this error:
    "Warning C4244: '+=' : conversion from 'double' to 'float', possible loss of data."

    note: I MUST use float for result and rate, and int for duration.

    For some reason, I'm allowed to do this
    Code:
    float result,rate;
    int duration;
    
    cin>>rate; 
    cin>>duration;
    result=rate*duration;
    result+=rate*duration;
    But I'm not allowed to do this
    Code:
    for(int i=0;i<slot;i++)
    {
    	gross[i]=rate[i]* hours[i];
    	if (hours[i]>40) gross[i]+=.5*(hours[i]-rate[i]); //Error here
    	}
    //the error is loss of data due to conversion from double to float
    //declared datatypes:
    //float: gross, rate
    //int: rate
    Thanks ^^

  2. #2
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    You're "not allowed?" Who is not allowing it? This is a warning, not an error. The compiler is simply making sure you realize what is happening.

    To eliminate the warning, provide an explicit cast. And try to get your head around the difference between a warning and an error.

  3. #3
    Registered User
    Join Date
    Jan 2005
    Posts
    7,366
    .5 is a double because double is the default floating point type in C++. If you have to use float, not double, change your literal to a float by adding an f:
    Code:
    if (hours[i]>40) gross[i]+=.5f*(hours[i]-rate[i]);
    >> note: I MUST use float for result and rate, and int for duration.
    Did you mean you must use float, or did you mean you must use a floating point type? If you meant the latter, then I would use double.

  4. #4
    Registered User
    Join Date
    Mar 2008
    Posts
    7
    Thanks Daved. This solves it for me =)

  5. #5
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    Question for the hardware people:

    What can modern CPUs manipulate faster: float or double (if this can be answered)? Does is depend on 32/64 bit mode?

    Thank you.

  6. #6
    Registered User
    Join Date
    Sep 2006
    Posts
    835
    I'm not a hardware person, but since the standard allows float and double to be the same size, there wouldn't be any reason to allow a smaller floating-point type if it was also slower, so I would think that float would always be at least as fast as double.

    Edit: Unless the implementation wanted to have 32- and 64-bit types coinciding with IEEE 754 float and double, but I still doubt that float would ever be slower.

  7. #7
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    maybe it's slower on some architecture and faster on another? I have no idea...

    BTW: Does anyone knows a reference where I could look up all size constraints for all PODs defined by the C++ standard?

  8. #8
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,412
    Does anyone knows a reference where I could look up all size constraints for all PODs defined by the C++ standard?
    You can find them in Annex E (Implementation limits) of the 1999 edition of the C Standard, but I am not sure where to find a draft. Strictly speaking the C++ Standard refers to the 1990 version (same as 1989) of the C Standard, but I do not think these implementation limits have changed.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  9. #9
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by robatino View Post
    I'm not a hardware person, but since the standard allows float and double to be the same size, there wouldn't be any reason to allow a smaller floating-point type if it was also slower, so I would think that float would always be at least as fast as double.

    Edit: Unless the implementation wanted to have 32- and 64-bit types coinciding with IEEE 754 float and double, but I still doubt that float would ever be slower.
    Yes, float as (on x87) always as fast or faster than double. Most other architectures are the same. Note however, that x87 will perform all calculations to full precision, and only the loading and storing of the value will be affected by the size. [Pedants: Yes, this is slightly simplified, but it's how things generally work].

    Of course, in some cases, a shorter float will make code faster simply because it takes up less space, thus you can fit more numbers in the cache, and get more work done in the same amount of memory space.

    And when using SSE or similar techniques, shorter float types fit more "floats" into one register, meaning more work can be done in a single instruction -> faster execution.

    The rule about "float and double can be the same size" is much more to satisfy machines that only have one floating point type - it can still compile code that uses either float or double. Just like long int isn't necessarily bigger than int - it's to allow 32-bit machines to have a 32-bit int, that is the same size as a long.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  10. #10
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    x87?
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  11. #11
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Elysia View Post
    x87?
    x87 is the name of the Intel/AMD FPU. The name stems from the time when a 387 was something that you'd plug in next to the Intel or AMD 386DX processor. Of course, these days, the FPU is part of the overall processor. But the functional unit is still behaving the same in a "black box" world.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  12. #12
    Registered User
    Join Date
    Jan 2005
    Posts
    7,366
    >> there wouldn't be any reason to allow a smaller floating-point type if it was also slower
    Yes there would. You would allow it for space saving reasons. Think of short and int.

  13. #13
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Huh, so the actual processor architecture is called x86 and the FPU in the x86 is called x87?
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  14. #14
    Registered User
    Join Date
    Sep 2006
    Posts
    835
    Quote Originally Posted by Daved View Post
    >> there wouldn't be any reason to allow a smaller floating-point type if it was also slower
    Yes there would. You would allow it for space saving reasons. Think of short and int.
    Yes, good point. In fact, even if it was slower in terms of CPU, the extra cache efficiency for a large array might make up for it, resulting in greater overall speed (if the bottleneck was memory access).

  15. #15
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by robatino View Post
    Yes, good point. In fact, even if it was slower in terms of CPU, the extra cache efficiency for a large array might make up for it, resulting in greater overall speed (if the bottleneck was memory access).
    Not to mention that if someone sent you a file with IEEE-754 32-bit floats that you had to process, it would be a right pain if the compiler decided that you couldn't do that at all because float is a 64-bit double for speed reasons. It's one thing if the HW has no choice, but if the HW supports the format, you certainly don't want the compiler to stop you from using it.

    [Not that it would be terribly hard to read the values into an array of the right type and write a 3-4 line assembler function to convert it, if the HW supports it].

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 2
    Last Post: 05-13-2009, 03:25 PM
  2. Im stuck....
    By dAzed in forum C++ Programming
    Replies: 8
    Last Post: 10-11-2004, 04:50 PM
  3. HUGE fps jump
    By DavidP in forum Game Programming
    Replies: 23
    Last Post: 07-01-2004, 10:36 AM
  4. Configurations give different results
    By Hubas in forum Windows Programming
    Replies: 2
    Last Post: 04-11-2003, 11:43 AM
  5. How do you search & sort an array?
    By sketchit in forum C Programming
    Replies: 30
    Last Post: 11-03-2001, 05:26 PM