Date: Fri, 25 Oct 2002 00:53:38 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: bde@zeta.org.au Cc: rittle@latour.rsch.comm.mot.com, current@FreeBSD.ORG Subject: Re: Lack of real long double support Message-ID: <20021025.005338.78502540.imp@bsdimp.com> In-Reply-To: <20021024205944.R1451-100000@gamplex.bde.org> References: <200210240833.g9O8XB1W033884@latour.rsch.comm.mot.com> <20021024205944.R1451-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20021024205944.R1451-100000@gamplex.bde.org>
Bruce Evans <bde@zeta.org.au> writes:
: On Thu, 24 Oct 2002, Loren James Rittle wrote:
:
: > ... Anyways, that work exposed some issues.
: >
: > We have this in the system header:
: >
: > #define LDBL_MANT_DIG DBL_MANT_DIG
: > #define LDBL_MIN_EXP DBL_MIN_EXP
: > #define LDBL_MAX_EXP DBL_MAX_EXP
: > [...]
:
: This seems to be correct. Long double precision is not really supported
: either at complie time or runtime. The default precision (on i386's)
: is 53 bits, so (normalized) long doubles have a hard time getting any
: larger than DBL_MAX or any smaller than DBL_MIN (you can create them
: as bits or using a hardware transcendental function, but any arithmetic
: on them will convert them to double precision).
That is incorrect. long double are supported at runtime. We use them
all the time and do get numbers outside the range of normal doubles.
There are some minor rounding issues with them, but those issues
result in a 1-2 bit rounding error in most of the cases I've looked at
in extreme detail. Such rounding errors do limit the effective range
to about 62 bits, but that's still a lot better than 53 bits you get
with doubles.
: gcc can't actually support the full range, since it doesn't control
: the runtime environement (it could issue a fninit before main() to
: change the default, but it shouldn't and doesn't). The exponent
: range is lost long before printf() is reached. E.g.,
:
: long double x= DBL_MAX;
: long double y = 2 * x;
:
: gives +Inf for y since the result is doesn't fit in 53-bit precision.
: The system header correctly reports this default precision. Any header
: genrated by the gcc build should be no different, since the build should
: run in the target environment.
that's not true. y is not +Inf, but prints as +Inf because printf and
friends do not support outside the range of a double.
If you were correct, the following program would say so:
#include <stdio.h>
#include <float.h>
int main(int argc, char **argv)
{
long double x = DBL_MAX;
long double y = x * 2;
long double z = x * 3;
if (y == z)
printf("bde is right\n");
else
printf("bde is not right\n");
}
but it prints that you are not correct. If you were correct, both y
and z would be the same (+Inf), but they are not (they both print as
+Inf, but that's a bug in our printf code). A version of the above
with doubles does show they are both the same (+Inf).
: Not really. Assembly is still required to get full control over precision.
: I'm still waiting for (C) language support to catch up. Been waiting for
: about 14 years so far. C99 clarified the semantics of floating point
: precision but is not supported by gcc (yet?).
This is not true.
: > Also, as an aside, having just learned everything there is to know
: > about IEEE FP from a witty 80-slide presentation on the WWW by one of
: > the original designers of the spec@Berkeley, I'd say that he would be
: > sad that we default to use 53-bit precision mode. I'd say that it is
: > dumb to claim we even support long double unless we change that to
: > 64-bit precision mode...
:
: I think he would be even unhappier with gcc's support for it. We default
: to 53-bit precision partly because Kahan's (his?) paranioa(1) is unhappy
: with 64-bit precision.
Kahan's paranoia is unhappy with 64-bit precision, but the unhappiness
is on the order of 1-2 bits of rounding error in the wrong direction.
Warner
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021025.005338.78502540.imp>