long double

[broli]

Is this a part of C 99 or just an addon in some windows compilers like
pellesC ?

 

[Ioannis Vranos]

Is this a part of C 99 or just an addon in some windows compilers like
pellesC ?

It has been a part of all C language standards: ISO C90, C95, C99.

 

[Philip Potter]

Basically it's a hardware question. Whilst floating point can be emulated in
software, if you have to do this it's unlikely that you need much precision.
If the hardware supports 80 bit floats then the C compiler has to support
them, in practise, or people would complain. I think it is actually part of
C99, for what it's worth, but that standard hasn't received wide acceptance,
so it doesn't really matter whether long double is in it or not.

You seem to be confused about what 'long double' means. There is no
requirement that long double be at least 80 bits. Although long double
is part of C99, it is not guaranteed to be any larger or store any more
values than double.

Philip

 

[jacob navia]

Is this a part of C 99 or just an addon in some windows compilers like
pellesC ?

long double is part of C99

 

[jacob navia]

Basically it's a hardware question.

No, the question was about the standard. The questions is
Are "long double"s part of C99?

There is no hint as to any hardware questions.

Whilst floating point can be
emulated in software, if you have to do this it's unlikely that you need
much precision. If the hardware supports 80 bit floats then the C
compiler has to support them, in practise, or people would complain.

No, this is completely wrong. The compiler can IGNORE them and if people
complain the compiler builders will not give a damm.

Example at hand: In Microsoft compilers, long double is the same as
double. The users are complaining since 10 years and they go on.

I
think it is actually part of C99, for what it's worth, but that standard
hasn't received wide acceptance, so it doesn't really matter whether
long double is in it or not.

And your opinion about C99 matters even less.

C99 is the current C standard, even if you persist on trying to
disqualify it.

 

[Keith Thompson]

long double is part of C99

Yes. long double is (was?) also part of C89/C90, and I'm reasonably
sure that the requirements for C90 did not change between C90 and C99.
C99 did make a minor change in the printf formats for long double, and
added math functions for long double, but made no change in the type
itself.

I don't know where this idea that long double is a C99-specific
feature came from, but it's mistaken. (I'm not suggesting that jacob
made this mistake; I'm just providing additional information.)

 

[jacob navia]

I don't know where this idea that long double is a C99-specific
feature came from, but it's mistaken.

Obviously this association was suggested by the question of the
OP that said:

Is long double part of C99?

 

[Bartc]

Is this a part of C 99 or just an addon in some windows compilers like
pellesC ?

Long double seems to be part of both C90 and C99 standards. And in both it
seems to be at least 32-bits.

Whether you get any more precision depends on your compiler, but it may not
necessarily be more than double.

 

[Bartc]

This needs some explanation. There must be at least
LDBL_DIG * lg(10) bit-equivalents in the fractional part
of a long double, and since LDBL_DIG must be at least 10
this implies a fraction of at least 33.2+ bit-equivalents.
There must also be enough distinct exponent values to cover
the range LDBL_MIN_10_EXP through LDBL_MAX_10_EXP, which
must be at least the range -37 through +37; 75 or more
distinct values implies lg(75) = 6.2+ bit-equivalents.
Finally there's the sign, for one more bit-equivalent. All
in all, long double needs at least 40.4+ bit-equivalents.

Since 40.4+ is "at least 32," you're right.

No, I missed that. I only saw the 1e37 maximum exponent across all float,
double, long double and assumed they were all the same, namely 32-bits.

But 40 bits is a very odd figure to put into a standard.

 

[Philip Potter]

This needs some explanation. There must be at least
LDBL_DIG * lg(10) bit-equivalents in the fractional part
of a long double, and since LDBL_DIG must be at least 10
this implies a fraction of at least 33.2+ bit-equivalents.

No, you only need (LDBL_DIG * lg(10) - 1) bit-equivalents in binary. In
binary floating point, the most significant bit is always 1 except for
unnormalised numbers, infinities, NaNs, and zero. The first three aren't
required to exist, and the minimum possible value can be defined to be zero.

There must also be enough distinct exponent values to cover
the range LDBL_MIN_10_EXP through LDBL_MAX_10_EXP, which
must be at least the range -37 through +37; 75 or more
distinct values implies lg(75) = 6.2+ bit-equivalents.
Finally there's the sign, for one more bit-equivalent. All
in all, long double needs at least 40.4+ bit-equivalents.

Since 40.4+ is "at least 32," you're right.

And hence I think you only need 39.4 bits in binary (and even in other
radices, you could probably exploit the fact that the most significant
digit is nonzero to reduce the requirement below 40.4 bits).

Right: the minimum requirements for long double's range
and precision are the same as those for plain double, so the
implementation is not obliged to do any better. It must not
do any worse, though.

Indeed. The set of double values are a subset of long double values.

Philip

 

[Philip Potter]

By writing "bit-equivalent," I was being careful not to
assume base two; in bases other than two (e.g., sixteen as
in IBM S/360), the "hidden bit" coding trick you mention is
rather difficult to employ ...

Indeed. But the standard allows binary, doesn't it? And so the minimum
size of long double has to take this into account. The fact that
nonbinary is also allowed doesn't stop binary systems from using the
hidden bit trick. And this is such a commonly-used trick that I think
it's well worth mentioning as a special case. The fact that C requires
an underlying binary representation means that binary is all-the-more
common -- although binary is good for implementing other powers of two,
and elsethread somebody has mentioned implementing decimal
floating-point on a binary architecture.

When I wrote "rather difficult" I was attempting an ironic
understatement, but perhaps the point needs more illustration.
Please assume base ten for familiarity's sake, and explain
how to avoid storing the leading digit of 3.14159E0. The fact
that the leading digit is non-zero is not sufficient for us to
determine what it actually is (as it would be in base two).

True, one could take advantage of the leading digit's non-
nullity by encoding it in the equivalent of lg(9) ~= 3.17 bits
rather than in lg(10) ~= 3.32 bits. One could even attempt a
variable-length encoding, taking advantage of the empirical
observation that the leading digit are usually small. But

No you couldn't. 'long double' (like all other types) must have a fixed
size, so a VLC isn't possible.

super-sophisticated encoding schemes have a way of chewing up
a lot of silicon, and chip designers are already peeved at the
area devoted to the FPU, and there's also the matter of speed ...

Perhaps you think I was seriously proposing such a system? No, I was
only mentioning it was possible, and somewhat facetiously too I might
add. None of this changes the fact that the theoretical minimum size of
long double is 39.4 bits.

Philip

 

[Richard Bos]

Obviously this association was suggested by the question of the
OP that said:

Is long double part of C99?

Yes, but where do _they_ (note that the current OP is hardly the only
one to ask this question) get this idea from?

Richard

 

[David Thompson]

<snip> [long double] seems to be at least 32-bits.

This needs some explanation. There must be at least
LDBL_DIG * lg(10) bit-equivalents in the fractional part
of a long double, and since LDBL_DIG must be at least 10
this implies a fraction of at least 33.2+ bit-equivalents.

Possibly minus 1 for hidden-bit, as already discussed.

There must also be enough distinct exponent values to cover
the range LDBL_MIN_10_EXP through LDBL_MAX_10_EXP, which
must be at least the range -37 through +37; 75 or more
distinct values implies lg(75) = 6.2+ bit-equivalents.

There is no need for the exponent's base to be 10. Commonly it is 2
(which allows maximum density of a binary significand, and hidden-bit)
and a dynamic range of 1e-/+37 is roughly 2 up -/+123 for 8 bits of
exponent. But S/360 uses 16 (as you noted) and needs only 6 bits of
exponent for the same range. And it would be legal to use a larger
base, but the loss in significand precision grows much faster than the
gain in reduced exponent size, so people don't.

<snip rest>
- formerly david.thompson1 || achar(64) || worldnet.att.net

 

[user923005]

Dann Corbit wrote:

... snip ...


And then you have to consider the added physical complexity of
building a flip-flap-flop (in place of a flip-flop), and
implementing tri-level gates, etc.

With +voltage, ground, -voltage the idea is so obvious I would guess
someone has tried it.

 

[user923005]

With +voltage, ground, -voltage the idea is so obvious I would guess
someone has tried it.

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

 

[Dik T. Winter]

> Dann Corbit wrote: ....
>
> And then you have to consider the added physical complexity of
> building a flip-flap-flop (in place of a flip-flop), and
> implementing tri-level gates, etc.

Has been done, and it was apparently not so very difficult.