James Kuyper
6/1/2011 1:22:00 PM
On 05/31/2011 04:36 PM, Ben Pfaff wrote:
> Simon <anon@nospam.com> writes:
>
>> I looked over the C99 spec for hexadecimal constants. They seem quite
>> odd on two accounts. For one, it is a binary exponent value, but the
>> other number is hexadecimal. Why not make them both hexadecimal? You
>> really don't lose anything...you just have to shift your radix point a
>> bit. This just seems confusing as it is.
>
> I have always assumed that hexadecimal constants were written in
> hexadecimal instead of binary just to save space. That is, the
> underlying representation of floating-point numbers is assumed to
> be in base 2, and one writes those in base 16 just to avoid
> making the textual representation very long.
Yes, that is the main purpose, depending upon how you meant it.
A floating point number with N bits of precision can be exactly in
ceil(N/4.0) hexedecimal digits, but requires ceil(N*ln(2)/ln(10)) (+1?)
decimal digits to be expressed with sufficient precision to uniquely
determine what all N of those bits should be. That's only a 20% more
digits; it's not much of an motivation for using hexadecimal notation.
However, to express the number exactly would require N decimal digits -
that's the big advantage of hexadecimal floating point constants.
This advantage only applies when FLT_RADIX is a power of 2, but that's
by far the most common case. The most common alternative to FLT_RADIX==2
is FLT_RADIX==16, which provides the same advantage. I've also heard of
platforms where FLT_RADIX of 3 or 10 would be appropriate, but I don't
know if any implementation of C was ever created for such platforms.
--
James Kuyper