# Thread: How large is a float?

1. ## 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. 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. 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. 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.

5. Every time you multiply it by 2, you are just incrementing the exponent by 1, because the mantissa is normalized.

6. Originally Posted by Subsonics
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. Originally Posted by roaan
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. Originally Posted by cyberfish
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. 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).

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]

10. Originally Posted by cyberfish
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).

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.

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

12. 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. Originally Posted by tabstop
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.

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

15. 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).