>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