> Claiming 53 bits but supporting 64, and then not raising an exception
> and/or giving a "NaN" or "INF" result on overflow to the 54th bit is
> broken. If you do this, you will fail runtime validation suites.
Huh? The 53-bit quantity refers to the mantissa not the exponent.
Unless I'm sorely co
Loren James Rittle wrote:
> I will advise RTH about that type of issue. Fortunately, in this
> case, I think advertising 53-bit precision but really using 64-bit
> precision (i.e. application code overrode system default) doesn't
> invalidate the advertised epsilon, in terms of how it is used by t
In article <[EMAIL PROTECTED]>,
Bruce Evans<[EMAIL PROTECTED]> writes:
>> If you really want, I can tell RTH that FreeBSD/i386 absolutely wants
>> `long double' to be:
>> 53 mantissa bits
>> 1024 max exponent
> No need. I prefer to keep the 53-bit precision for now, but fix the
> exponents.
OK
On Thu, 24 Oct 2002, Loren James Rittle wrote:
> >> ... Anyways, that work exposed some issues.
> ...
> It is easy to generate, with arithmetic, a long double value outside
> the *exponent* range above no matter how the precision is set; it is
> not truncated to Inf until it is actually cast to a
Thanks for the quick answer Bruce. Based on the statement: ``It
should use whatever is the default format for the host environment''
and the statements that make it clear gcc isn't changing its default
precision setting anytime soon, I think I now know how to make a
correct patch for the FSF gcc m
On Thu, 24 Oct 2002, Loren James Rittle wrote:
> ... Anyways, that work exposed some issues.
>
> We have this in the system header:
>
> #define LDBL_MANT_DIG DBL_MANT_DIG
> #define LDBL_MIN_EXPDBL_MIN_EXP
> #define LDBL_MAX_EXPDBL_MAX_EXP
> [...]
This seems to be correct. Long double
