Also, if one feels the tolerance of a single float discrepancy is too small, this can be addressed by calling nextafter() multiple times:

float_is_int (double x)
{
  double absx = fabs (x);
  double roundabsx = gnulib::round (absx);
  double na = nextafter (absx, roundabsx);
  if (na == roundabsx)
    return true;
  else
    {
      na = nextafter (na, roundabsx);
      if (na == roundabsx)
        return true;
      else if (nextafter (na, roundabsx) == roundabsx)
        return true;
    }
  return false;
}

However, I'm inclinded to assume the tolerance of one floating point number away is adequate until shown otherwise.  A test script with a good test should indicate if that isn't adequate on some developer's computer.

The attached changeset is a hybrid of the existing Range algorithm for integer elements and a new Range algorithm for non-integer elements that attempts to "integerize" the underlying problem as a linear spacing.  It basically covers all the combinations of limits and range as a whole number of increments.  It seems to work pretty robustly, and at the same time avoids immediately converting a Range object to a matrix_value object.  So the improvement appears to be better numerical behavior in the circumstance most common where the user enters evenly spaced decimal numbers (-2:.1:.1) and even scalings inside the range such as (-N*pi:0.1*pi:N*pi).

Actually, there isn't too much new here.  I think it is more a case of organizing things well enough to have the various float_is_int variations for the limits/increment.  The patch chooses either an algorithm good for integers or one good for floats.  I've centralized the algorithm so one can tweak things pretty easily.

No need for a "convert to matrix_value" compile option.

I tried incorporating GNU library's ceil(), fabs(), and nextafter() functions into the project, similar to gnulib::floor(), but I don't think I quite figure it out.  I have some form of these routines in place though.  I wanted to ensure they were all the gnulib routines because presumably these all work nicely together in terms of floating point bit behavior.

We really need some tests for the range function, e.g., "test ::" or something like.  The dodgy part is declaring a float to be the equivalent of an int.  I've used within one floating point difference with the "nextafter" command.  There is some other existing code that appears to use three floating point numbers away.  Anyway, this could be hardware specific, depending upon the number of guard bits and resolution used internal to the ALU.  I'm assuming that most processors use lots of extra bits internally so that the math operations come out within a bit of the IEEE Float value.

I removed the unused member functions

  Range::set_base
  Range::set_limit
  Range::set_inc

because it seems like those parameters should remain encapsulated, untouched by outside code.  Changing those values has a lot of ramifications on other parameters.  An external class modifying those parameters directly doesn't take that into account.

I've also included a file of some sample range commands.