Best way of checking if a floating point is an integer

Question

[There are a few questions on this but none of the answers are particularly definitive and several are out of date with the current C++ standard].

My research shows

Answer 1

The problem with:

  if (   f >= std::numeric_limits::min()
      && f <= std::numeric_limits::max()
      && f == (T)f))

is that if T is (for example) 64 bits, then the max will be rounded when converting to your usual 64 bit double :-( Assuming 2's complement, the same is not true of the min, of course.

So, depending on the number of bits in the mantisaa, and the number of bits in T, you need to mask off the LS bits of std::numeric_limits::max()... I'm sorry, I don't do C++, so how best to do that I leave to others. [In C it would be something along the lines of LLONG_MAX ^ (LLONG_MAX >> DBL_MANT_DIG) -- assuming T is long long int and f is double and that these are both the usual 64 bit values.]

If the T is constant, then the construction of the two floating point values for min and max will (I assume) be done at compile time, so the two comparisons are pretty straightforward. You don't really need to be able to float T... but you do need to know that its min and max will fit in an ordinary integer (long long int, say).

The remaining work is converting the float to integer, and then floating that back up again for the final comparison. So, assuming f is in range (which guarantees (T)f does not overflow):

  i  = (T)f ;         // or i  = (long long int)f ;
  ok = (i == f) ;

The alternative seems to be:

  i  = (T)f ;         // or i  = (long long int)f ;
  ok = (floor(f) == f) ;

as noted elsewhere. Which replaces the floating of i by floor(f)... which I'm not convinced is an improvement.

If f is NaN things may go wrong, so you might want to test for that too.

You could try unpacking f with frexp() and extract the mantissa as (say) a long long int (with ldexp() and a cast), but when I started to sketch that out it looked ugly :-(

---

Having slept on it, a simpler way of dealing with the max issue is to do: min <= f < ((unsigned)max+1) -- or min <= f < (unsigned)min -- or (double)min <= f < -(double)min -- or any other method of constructing -2^(n-1) and +2^(n-1) as floating point values, where n is the number of bits in T.

(Serves me right for getting interested in a problem at 1:00am !)