How large is a float?

This is a discussion on How large is a float? within the C Programming forums, part of the General Programming Boards category; I would normally think that I knew the answer but I tried this: Code: #include <stdio.h> int main() { float ...

  1. #1
    Registered User
    Join Date
    Jan 2009
    Posts
    1,485

    How large is a float?

    I would normally think that I knew the answer but I tried this:

    Code:
    #include <stdio.h>
    
    int main()
    {
            float test = 8388607;
            int i;
    
            for(i = 23; i < 130; i++){
                    printf("%d bits: %f\n", i, test);
                    test *= 2;
            }
    
            return 0;
    }
    I keep getting answers until it reaches 129 where it just says: inf. My mind is blown, can some one explain lol.

  2. #2
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,183
    Floating point numbers don't work the same way as integers. *2 is not a shift.

    You are just making the number larger than the range for float, so it gets assigned a special value "inf".

  3. #3
    Registered User
    Join Date
    Jun 2009
    Location
    US of A
    Posts
    305
    As with all the data types there is a limit to what a number can hold. To understand why it gives INF just try out the following program.

    [insert]
    Code:
    #include <stdio.h>
    #include <float.h>
    
    int main()
    {
            float test = 8388607;
            int i;
    
            for(i = 23; i < 130; i++){
                    printf("%d bits: %f\n", i, test);
                    test *= 2;
            }
    
    		printf("The maximum value of float can be %.20e\n", FLT_MAX);
    	    printf("The minimum value of float can be %.20e\n", FLT_MIN);
    
    		printf("\n Size of float %d", sizeof(float));
            return 0;
    }
    So you have hit the max limit for float in your case and its not possible to go beyond that!!!!!!!!!!

  4. #4
    Registered User
    Join Date
    Jan 2009
    Posts
    1,485
    I'm not surprised to see inf. but I would expect it to show up much sooner. I mean, I have looked over IEEE 745 for floating point representation, and a float (assuming it's 32 bits now) should then have the first bit (going from the left) be the signed bit, then the following 8 for the exponent then there should be 23 bits left for the actual value in the mantissa. I actually expected to see inf directly after the first iteration of the loop. I mean looking at the code I supplied it would seem like a float is 128bits wide, not counting the exponent and the signed bit.
    Last edited by Subsonics; 08-22-2009 at 10:11 AM.

  5. #5
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,183
    Every time you multiply it by 2, you are just incrementing the exponent by 1, because the mantissa is normalized.

  6. #6
    Registered User
    Join Date
    Jun 2009
    Location
    US of A
    Posts
    305
    Quote Originally Posted by Subsonics View Post
    I'm not surprised to see inf. but I would expect it to show up much sooner.
    You can only expect to see the limit reached when it hits the upper limit for the system not when we wish it should.... So in your case in the 128th iteration it hits the max limit and in the 129th iteration it has hit the min limit (i think it has just wound up to the other side of the range probably)

  7. #7
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,183
    Quote Originally Posted by roaan View Post
    You can only expect to see the limit reached when it hits the upper limit for the system not when we wish it should.... So in your case in the 128th iteration it hits the max limit and in the 129th iteration it has hit the min limit (i think it has just wound up to the other side of the range probably)
    That's only true for integers, and only if you overflow it in a certain way.

  8. #8
    Registered User
    Join Date
    Jan 2009
    Posts
    1,485
    Quote Originally Posted by cyberfish View Post
    Every time you multiply it by 2, you are just incrementing the exponent by 1, because the mantissa is normalized.
    Okey, but how does it keep track of the decimal placement? My previous understanding was that the precision was 23 bits and you could make the value larger or smaller by moving the decimal point, handled by the exponent.

  9. #9
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,183
    It's like scientific notation. in 3.94*10^9, the mantissa is 3.94, which is always normalized to the range [1, 2), the exponent is 9, and the sign bit is 0 (for positive). The decimal point is always after the first significant figure (a non-zero).

    Floating point numbers work in the exact same way, except it's in base 2 (so the binary point is always before the first 1 bit in mantissa).

    [edit]I think I made a mistake. The binary point is to the left of the most significant 1 in the mantissa, since a leading 1 is assumed). Corrected above.[/edit]
    Last edited by cyberfish; 08-22-2009 at 10:32 AM.

  10. #10
    Registered User
    Join Date
    Jan 2009
    Posts
    1,485
    Quote Originally Posted by cyberfish View Post
    It's like scientific notation. in 3.94*10^9, the mantissa is 3.94, which is always normalized to the range [1, 2), the exponent is 9, and the sign bit is 0 (for positive). The decimal point is always after the first significant figure (a non-zero).

    Floating point numbers work in the exact same way, except it's in base 2 (so the binary point is always before the first 1 bit in mantissa).

    [edit]I think I made a mistake. The binary point is to the left of the most significant 1 in the mantissa, since a leading 1 is assumed). Corrected above.[/edit]
    Okey, thanks for clearing that up. I think my mistake might have been that I assumed base 10. I mean then all that would happen, would be added zeroes for every increment of the exponent.
    Last edited by Subsonics; 08-22-2009 at 10:37 AM.

  11. #11
    Registered User
    Join Date
    Jan 2009
    Posts
    1,485
    Wait, I'm still confused. I added an extra 7 to the first assignment of test, to the end of the program like this:

    Code:
            test = 83886077;
            printf("%f\n", test);
    The result I get of this is: 83886080


    Thanks for the FLT_MAX, FLT_MIN btw roaan, I was looking for something like that previously.
    Last edited by Subsonics; 08-22-2009 at 11:30 AM.

  12. #12
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,185
    83886077, in binary, is 0100 1111 1111 1111 1111 1111 1101, which as you can see, requires 27 bits. The best we can do with 23+1 bits of mantissa is to make the mantissa (1.)01 followed by a lot of zeroes. 1.01 x 2^26 gives 83886080.

    You should go here.

  13. #13
    Registered User
    Join Date
    Jan 2009
    Posts
    1,485
    Quote Originally Posted by tabstop View Post
    83886077, in binary, is 0100 1111 1111 1111 1111 1111 1101, which as you can see, requires 27 bits. The best we can do with 23+1 bits of mantissa is to make the mantissa (1.)01 followed by a lot of zeroes. 1.01 x 2^26 gives 83886080.

    You should go here.
    Aha, but then the precision is 23 bits still, so I guess if precision is important no larger values than 23bit wide should be stored in a float but a double. I just added a random number to see the response of going beyond the 23 bits in the mantissa to get a better understanding.

    That's a great link! Thanks for that I will look it over.
    Last edited by Subsonics; 08-22-2009 at 12:46 PM.

  14. #14
    Registered User
    Join Date
    Jan 2009
    Posts
    1,485
    So I have looked this over a bit and I have some more questions. If I have understood this correctly the mantissa is interpreted as having a decimal point after the first digit like 1.xxxx then the number is broken down until it have this form. So for example 75 would be represented like 75*2^0 leading to 1.171875*2^6. Now, to what point is this taken care of by the hardware? For example the assumed decimal point in the mantissa. I have seen some additional macros in float.h and there are a FLT_ROUNDS for rounding policies which have five modes. Are these modes language dependent or is it something that is dealt with by the CPU hardware?
    Last edited by Subsonics; 08-23-2009 at 05:12 AM.

  15. #15
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,183
    Well, C standard says nothing about implementations, but for x86 and common implementations, everything is taken care of by the FPU co-processor (even though they live under the same roof as the CPU now).

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 2
    Last Post: 05-13-2009, 04:25 PM
  2. Replies: 14
    Last Post: 06-28-2006, 02:58 AM
  3. Could somebody please help me with this C program
    By brett73 in forum C Programming
    Replies: 6
    Last Post: 11-25-2004, 02:19 AM
  4. Half-life SDK, where are the constants?
    By bennyandthejets in forum Game Programming
    Replies: 29
    Last Post: 08-25-2003, 12:58 PM
  5. How do you search & sort an array?
    By sketchit in forum C Programming
    Replies: 30
    Last Post: 11-03-2001, 05:26 PM

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