[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lmi] Is DBL_MAX "adjacent" to infinity? [Was: Two kinds of precision lo

From: Greg Chicares
Subject: [lmi] Is DBL_MAX "adjacent" to infinity? [Was: Two kinds of precision loss]
Date: Fri, 24 Mar 2017 19:36:44 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0

On 2017-03-23 00:27, Greg Chicares wrote:
> Oh, and here's another question. What happens if you try
>   static_cast<float>(DBL_MAX)?
> C++11 [4.8/1] says "If the source value is between two adjacent destination
> values, the result of the conversion is an implementation-defined choice of
> either of those values. Otherwise, the behavior is undefined." So is this
> cast UB? Or is DBL_MAX "adjacent" to infinity?
> And what about
>   static_cast<float>((double)INFINITY)
> ? AIUI, the C and C++ standards supposedly defer to the floating-point
> standard, and IEEE 754-1985 [6.1] defines "conversion of an infinity into
> the same infinity in another format" as an operation that signals no
> exceptions, so I think this is supposed to be well defined. OTOH, it's
> not "between two adjacent destination values", so is it UB?
> Can it be that
>   DBL_MAX is too big to convert to float, but
>   INFINITY is not too big to "   "   "
> even though DBL_MAX < INFINITY?

I happened upon this:


It cites the C equivalents of C++11's [conv.double] and [conv.fpint],
exhorts us to avoid the undefined behavior noted there, and then says:

| This rule does not apply to demotions of floating-point types on
| implementations that support signed infinity, such as IEEE 754,
| as all values are within range.

OTOH, their "safe" version of
  float f = whatever;
  int i = (int) f;
signals an error if the value to be converted is
 - out of range (determined by computing its logarithm), or
 - subnormal
but does not check for NaN...so their advice seems unreliable.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]