Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 1 Nov 2002 17:13:08 +1100 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        "M. Warner Losh" <imp@bsdimp.com>
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:  <20021101165954.M14075-100000@gamplex.bde.org>
In-Reply-To: <20021031.151847.03097281.imp@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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).

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.

Bruce


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?20021101165954.M14075-100000>