Mail Archives: djgpp/1999/01/11/11:55:28
On Mon, 11 Jan 1999, Charles Krug wrote:
> > Why should you care about different types of a NaN?
>
> If I'm creating a standard header file, then yes, I do care.
``Care'' was really meant to say ``care about the difference''.
In other words, since signalling and non-signalling NaN produce the same
effect in DJGPP, you could define both to the same bit pattern, the one
returned by nan().
Would this solve the problem for your version of <limits>?
> If the mantissa of a floating point number is too small to be represented
> in normalized form using the lowest allowed exponent, it may either be
> turned into zero, or represented in denormalized form--without an implicit
> leading 1. A denormalized result is usually indicated by a status flag.
> If this is the case, then float::has_denorm is true, and float::denorm_min
> is smaller than float::min--which represents the smallest normalized value
> for float. If this is not the case, then float::has_denorm is false, and
> float::denorm_min is the same value as float::min.
DJGPP doesn't do anything special; it just inherits the default operation
mode of the x87 processor.
As far as I understand, this means that denormals *can* happen, and when
they do, the suitable bit in the x87 status word is set (but no FP
exception is generated). See the docs of library function `_status87'
for the definition of the bits.
- Raw text -