Date: Fri, 01 Nov 2002 00:30:27 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: bde@zeta.org.au Cc: tlambert2@mindspring.com, rittle@labs.mot.com, rittle@latour.rsch.comm.mot.com, current@FreeBSD.ORG, dschultz@uclink.Berkeley.EDU Subject: Re: Lack of real long double support Message-ID: <20021101.003027.102770824.imp@bsdimp.com> In-Reply-To: <20021101165954.M14075-100000@gamplex.bde.org> References: <20021031.151847.03097281.imp@bsdimp.com> <20021101165954.M14075-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20021101165954.M14075-100000@gamplex.bde.org>
Bruce Evans <bde@zeta.org.au> writes:
: On Thu, 31 Oct 2002, M. Warner Losh wrote:
:
: > In message: <3DC17FC5.AF56552E@mindspring.com>
: > Terry Lambert <tlambert2@mindspring.com> writes:
: > : "M. Warner Losh" wrote:
: > : > : I await an explanation of how you can fit 2*DBL_MAX into a double,
: > : > : which has a range of DBL_MIN..DBL_MAX.
: > : >
: > : > Look at the code.
: > : >
: > : > long double a = DBL_MAX;
: > : > long double b = DBL_MAX * 2;
: > : >
: > : > The original posting said that b would be +Inf at this point, which is
: > : > not correct. I think that Bruce was confused there. The more correct
: > : > example to look at was the one that rittle@ posted which was 1 +
: > : > LDBL_EPSILON.
: > :
: > : I guess I must not be understanding. What will b be, at this point,
: > : then? How can it have a value larger than DBL_MAX that's not +Inf?
: > :
: > : If it's possible to represent a value larger than DBL_MAX in a double,
: > : then the value of DBL_MAX is wrong, right? Maximum means maximum,
: > : doesn't it?
: >
: > *LONG*DOUBLE* is not *DOUBLE*. long double has extended precision and
: > a range compared to double. That's how.
:
: To beat this dead horse some more: look at the code carefully. It was
:
: long double x= DBL_MAX;
: long double y = 2 * x; /* (1) */
:
: This is quite different from the above, which (after renaming variables
: and changing the formatting to be bug for bug compatible) is:
:
: long double x= DBL_MAX;
: long double y = DBL_MAX * 2; /* (2) */
:
: In (1), we have DBL_MAX in a long double, so we can expect to double it
: if long doubles are longer than doubles (whether they actually are is
: machine-dependent).
Right, The first example will not be +inf if long doubles have a
greater range than doubles. On our i386 implemenation, it does.
: In (2), we are doubling DBL_MAX as a double. The result of this is
: fuzzy, since the computation may be done in double precision or long
: double precision or perhaps something weirder. There will be no way
: to tell until C99 is implemented and perhaps not even then. gcc things
: that it is implementing C99's FLT_EVAL_METHOD of 0, which performs
: arithmetic on doubles in double precision, so the result of DBL_MAX *
: 2 is +Inf if the this is evaluated at compile time. gcc (gcc-3.2 on
: i386's) doesn't actually implement this, since the result is not +Inf
: if DBL_MAX * 2 is evaluated at runtime.
That's true, but that's also independed problem.. It is no different than
unsigned long long int a = ~0UL;
unsigned long long int b = a * 2;
vs
unsigned long long int a = ~0UL;
unsigned long long int b = ~0UL * 2;
In the first case, b is twice a. In the second, b is 1 less than a on
two's compliment machines.
I'd written 2.0L in my test code, and I think that it was originally
that way.
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?20021101.003027.102770824.imp>