From owner-freebsd-current Thu Oct 31 23:31:20 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBA6037B401 for ; Thu, 31 Oct 2002 23:31:17 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13D6343E4A for ; Thu, 31 Oct 2002 23:31:17 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id gA17VFpk058596; Fri, 1 Nov 2002 00:31:15 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 01 Nov 2002 00:30:27 -0700 (MST) Message-Id: <20021101.003027.102770824.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 From: "M. Warner Losh" In-Reply-To: <20021101165954.M14075-100000@gamplex.bde.org> References: <20021031.151847.03097281.imp@bsdimp.com> <20021101165954.M14075-100000@gamplex.bde.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20021101165954.M14075-100000@gamplex.bde.org> Bruce Evans writes: : On Thu, 31 Oct 2002, M. Warner Losh wrote: : : > In message: <3DC17FC5.AF56552E@mindspring.com> : > Terry Lambert 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