Date: Thu, 31 Oct 2002 11:08:53 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: bde@zeta.org.au, 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: <3DC17FC5.AF56552E@mindspring.com> References: <3DC0D732.C29B956C@mindspring.com> <20021031.001532.99559440.imp@bsdimp.com> <3DC0E0A7.290A57CA@mindspring.com> <20021031.013338.106483974.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"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? > : I think that a number that's a 64 bit mantissa reaised to an exponent > : N takes a larger N if you have only 53 bits of mantissa, if you want > : to represent the same value. > > Nope. The only difference between 53 bits and 64 bits of precision is > just that: precision. The number of bits for expoentent is > independent of this. .125 ^ 2 = 0.015625 .25 ^ 3 = 0.015625 So if I go from 3 digits of precision to 2 digits of precision for my mantissa, in order to represent the same number, I need a larger exponent. > This is true. Granting, for the moment, that fpgetprec() == FP_PE > isn't a standards conforming expression. > > But I think that the rest of this is going off into the weeds. I'm > just trying to get things working in a sane way for long doubles. It > looks like gcc 3.2 really wants the fpu to start off in FP_PE. There has to be an agreement between the host OS and the compiler; that's what makes C99 more complicated than it needed to be. > Before I go forward on this further, I've got a lot of testing to do > with kernels and such to find out what really works and what does (and > doesn't) break paranoia.c. That's one test. Another is: http://www.glenmccl.com/c9suite.htm Unfortunately, it's $8495 for everything. 8-(. There's also the stuff I wrote, which doesn't test range/domain overflows, etc., but at least complains when things are not defined or prototypes are out of scope (i.e. it mostly just complains about header file contents). -- Terry 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?3DC17FC5.AF56552E>