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.Originally Posted by tabstop
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.
In the hardware. The point about the five modes is not that you get to choose -- the macro returns the corresponding value to the way your system works, in case you need to know. (You can see whether the behavior is changeable and try to change the behavior with the functions/macros in <fenv.h>.)
Hmm, I found the function fesetround() in C in a nutshell, I haven't tried to use it though, I assume that mode 1 "Round to nearest representable value" is preferable in most cases, it was also what I got back from checking FLT_ROUND.
Well, there is a slight catch: "Even though the rounding direction macros may expand to constants corresponding to the values of FLT_ROUNDS, they are not required to do so." That is, the numbers you get back from fegetround/fesetround don't have to match (I think any implementation with one-third of a brain would make it so, but anyway), so to be safe you should test against FE_TONEAREST (or whichever rounding method you want to use).
That's interesting, I printed FLT_ROUNDS which got me 1, then I did the same with FE_TONEAREST which then gave me 0. Thanks for pointing that out. Okey now I tried fegetround() and it returns 0 aswell, shouldn't the FLT_ROUNDS correspond whith what fegetround() returns?
Last edited by Subsonics; 08-23-2009 at 11:25 AM.
