Can a double be 32 bits?

I

Ian Collins

spasmous said:
Just wondering.

About what?

Ah, I see, please put your question in the body of your message.

Can a double be 32 bits?

No, 32 bits is too small.
 
S

spasmous

About what?

Ah, I see, please put your question in the body of your message.

Can a double be 32 bits?

No, 32 bits is too small.

I can't locate anywhere official-looking that it says this. Does the C
standard mandate some minimum number of bits?
 
B

Bartc

I can't locate anywhere official-looking that it says this. Does the C
standard mandate some minimum number of bits?

Aparently the minimum is 10 decimal digits. With the exponent added, 32 bits
is not enough.

In practice a double will likely be 64 bits. But with C nothing is ever
certain.
 
W

Walter Roberson

I can't locate anywhere official-looking that it says this. Does the C
standard mandate some minimum number of bits?

No, but it mandates minimum value ranges and minimum precisions.
About a week ago, there was a calculation posted showing that
approximately 40.4 value bits would be required to meet the specification;
with 1 "hidden bit", it is perhaps doable in 40 bits. But not 32.
 
J

James Harris

....



Even without the exponent, it takes ~33.22 bits to maintain correctly 10
decimal digits, and we also need to be able to store an exponent of +/-37,
requiring ~5.2 bits so 39 bits +2 bits for signs (one implicit) gives us 40
bits as a mathematical bare minimum that we could expect to be used for data
type double in the C language.

5.2 bits??? I think the exponent is stored in binary so would need to
be larger. Assuming the exponent can be in the range

from: 10 ** -37
to : 10 ** 37

since

log2(10 ** -39) = -129.55519570060713
log2(10 ** -38) = -126.23326760571979
log2(10 ** -37) = -122.91133951083242

log2(10 ** 37) = 122.91133951083242
log2(10 ** 38) = 126.23326760571976
log2(10 ** 39) = 129.55519570060713

the exponent seems to need a value in the range -123 up to +123 (247
values) and therefore would need 8 bits. Interestingly it looks like
the range for 10 ** +/- 38 could just be accommodated in eight bits as
it needs -127 up to 127 (255 values) leaving one value to indicate
others such as NaNs.
 
U

user923005

5.2 bits??? I think the exponent is stored in binary so would need to
be larger. Assuming the exponent can be in the range

from: 10 ** -37
to  : 10 ** 37

since

log2(10 ** -39) = -129.55519570060713
log2(10 ** -38) = -126.23326760571979
log2(10 ** -37) = -122.91133951083242

log2(10 ** 37) = 122.91133951083242
log2(10 ** 38) = 126.23326760571976
log2(10 ** 39) = 129.55519570060713

the exponent seems to need a value in the range -123 up to +123 (247
values) and therefore would need 8 bits.

If you read carefully, you will see that I reserved an extra bit for
the sign.

pow(2,
5.20945336562894978185780417761317549976142496967218804875166362214168539064)
is ~37
Hence, 5.2 bits.
Interestingly it looks like
the range for 10 ** +/- 38 could just be accommodated in eight bits as
it needs -127 up to 127 (255 values) leaving one value to indicate
others such as NaNs.

The C standard only asks for +/-37 and so trying to obtain 38 is not
salient.

It would be possible to physically store floating numbers using
artithmetic compression, so fractional bits are possible.
 
J

James Harris

....
If you read carefully, you will see that I reserved an extra bit for
the sign.

Sure (though an exponent is normally stored biased and non-negative so
doesn't have a sign bit per se) but neither 5, 5.2, nor (with an extra
'sign' bit) 6 or 6.2 bits seem to be enough. I was saying that (if the
mantissa is a binary number as normal) the exponent will need to range
from -123 to +123, not -37 up to +37. (2 ** 123 is a little over 10 **
37 to cover the exponent of +/- 37 that you mention is needed for C) I
think you therefore need 8 bits for the exponent for the C requirement
of 10 ** +/- 37.

You could possibly make the mantissa a decimal number and then use
your 5.2 or 6.2 bits figure but a decimal number would not be stored
as efficiently as a binary one and would therefore store less in a
given space.

....
The C standard only asks for +/-37 and so trying to obtain 38 is not
salient.

My comment was the other way round, i.e. given that an 8-bit exponent
is needed (as it is to hold the 247 values from -123 up to 123) it can
hold higher numbers using some of the 9 remaining values (256 - 247 =
9). At least one of the values needs to be reserved for NaNs etc but
that still seems to allow 10 ** +/- 38. It would depend on the
representation.
 
D

Dik T. Winter

> log2(10 ** -38) = -126.23326760571979
> log2(10 ** -37) = -122.91133951083242
>
> log2(10 ** 37) = 122.91133951083242
> log2(10 ** 38) = 126.23326760571976 ....
> the exponent seems to need a value in the range -123 up to +123 (247
> values) and therefore would need 8 bits. Interestingly it looks like
> the range for 10 ** +/- 38 could just be accommodated in eight bits as
> it needs -127 up to 127 (255 values) leaving one value to indicate
> others such as NaNs.

It all depends on how hardware implements floating point. For instance
on the PDP and the VAX (where C did originate), the maximum exponent
was 126 and the minimum exponent was -128 (the bias was 129). When
you read the literature you will find a bias of 128, but on those machines
the binary point was in *front* of the first bit of the mantissa, in IEEE
it is just behind that first bit. When you move the point one place, you
shift the true exponent by one. Floating point representation is a bit
tricky.
 
U

user923005

...







Sure (though an exponent is normally stored biased and non-negative so
doesn't have a sign bit per se) but neither 5, 5.2, nor (with an extra
'sign' bit) 6 or 6.2 bits seem to be enough. I was saying that (if the
mantissa is a binary number as normal) the exponent will need to range
from -123 to +123, not -37 up to +37. (2 ** 123 is a little over 10 **
37 to cover the exponent of +/- 37 that you mention is needed for C) I
think you therefore need 8 bits for the exponent for the C requirement
of 10 ** +/- 37.

You could possibly make the mantissa a decimal number and then use
your 5.2 or 6.2 bits figure but a decimal number would not be stored
as efficiently as a binary one and would therefore store less in a
given space.

...



My comment was the other way round, i.e. given that an 8-bit exponent
is needed (as it is to hold the 247 values from -123 up to 123) it can
hold higher numbers using some of the 9 remaining values (256 - 247 =
9). At least one of the values needs to be reserved for NaNs etc but
that still seems to allow 10 ** +/- 38. It would depend on the
representation.

http://en.wikipedia.org/wiki/Arithmetic_coding
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,432
Messages
2,571,681
Members
48,796
Latest member
Greg L.

Latest Threads

Top