I would normally think that I knew the answer but I tried this:
I keep getting answers until it reaches 129 where it just says: inf. My mind is blown, can some one explain lol.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; }
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".
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]So you have hit the max limit for float in your case and its not possible to go beyond that!!!!!!!!!!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; }
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 09:11 AM.
Every time you multiply it by 2, you are just incrementing the exponent by 1, because the mantissa is normalized.
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)Originally Posted by Subsonics
That's only true for integers, and only if you overflow it in a certain way.
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.
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 09:32 AM.
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 09:37 AM.
Wait, I'm still confused. I added an extra 7 to the first assignment of test, to the end of the program like this:
The result I get of this is: 83886080Code:test = 83886077; printf("%f\n", test);
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 10:30 AM.
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 11:46 AM.
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 04:12 AM.
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).
