"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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
