[prog] c types confusion

[dominik.schramm at gmxpro.net]

Hi again,

Alice Moomlyn <alice_moomlyn at yahoo.com> writes:

> I was doing a plain old:
>
> man printf 
>
> and getting:
>
> man 1 printf 

Oh yes, I should have mentioned that. 

> I think that the truth of the matter is that I don't
> really understand how floating point numbers are
> represented in a computer. But I always imagined it
> was something like this:
> [...]
> Those 32 bits now have to be split between the base (I
> don't think that's quite the right word) and the
> exponent (mantissa?).

Something like this definitely, yes. But how exactly this is done 
is architecture dependent: On Intel systems (and compatibles?) floats
are stored (if I recall correctly!) according to the so-called 
IEEE floating point format:

for 32bit floats:
bit 31                            bit 0
seee eeee.emmm mmmm.mmmm mmmm.mmmm mmmm

where s is the sign bit, the 8 e-bits represent the exponent E
-- "excess-127 code" --, the 23 m-bits represent the mantissa M.

The actual number is then

N = (-1)^s * 2^(E-127) * (1.M)     (that's "1 point M" at the end!)

As you can see, the base is 2! That means that powers of 2 can always 
be stored exactly: M = 0, thus N = (-1)^s * 2^(E-127) * 1

This means that absolute numbers from 1.0*2^-127 = 5.877e-39
to 2*2^128 = 2^129 = 6.806e38 can be represented this way, with
an accuracy of 23 binary places after the point, that is about 
7 or 8 decimal places.

> So if you have: 2.456e14 then you'd have x bits to
> store the 2456 and y bits to store the 14 and you are
> constrained by x + y = 32.

Originally I wanted to take this number for an example. But I'm not so
sure any more that you really wanted to know how floats are stored 
exactly...
 
> Now, 2^32 = 4294967296 = 4.294967296e9, and its going
> to take all your 32 bits to store the: 4.294967296,
> leaving nothing to store the: 9, so won't it get
> approximated to: 4.294967e9, or something?

Yes it will, see Daniel's response.

regards,
dominik