Hummmm... I've been looking at the code and I wonder if it will always work with floating point values? Stepping through the interval involves adding the step value at each increment, but asking if a value is in the interval involves modulo arithmetic. The problem comes when the step value cannot be exactly represented in binary (0.7 for example).
I can't believe it will always work identically, but I've not been able to come up with a test case that fails.
My reaction is: of course it doesn't work for floats. Here is a counterexample:
(31 to: -13 by: -7/3 asFloat) includes: -4 => false (31 to: -13 by: -7/3 asFloat) asArray includes: -4 => true
This is on a PPC; I would gess that the particular floating point hardware might make a difference.
The problem is that -35\(-7/3)asFloat => -2.33333333333333, when one would hope to get zero.
Personally, I'm not in the least worried about this, because I would not expect the do: method or any of the other interval methods to work predictably with floats. This reminds me of one of the first bugs that I found while working as a "programming consultant" at the local Polytechnic. An economist had changed his "for loop" from
for year := 1974 by 0.25 to 2000 do ...
to
for year := 1974 by 0.2 to 2000 do ...
and was wondering why his magnetic tapes were no longer being rewound. The answer, of course, is that he was testing for "year = 2000" .
Rather appropriate that this Y2K bug should resurface just now :-)
Andrew