-the fix by Boris efectively removes the bug it describes.

-while doing the fix, an #asFloat is removed from the calculation; so
far I see no side effects, but perhaps someone put it in there for some
special case I can't imagine now, so this could be problematic

-reviewing the original implementation, I see that while it pretends to
avoid going through the list of possible values, this leads to extrange
answers like the following one:

(1 to: 5 by: 1) includes: 2     --> obvioulsy true
(1 to: 5 by: 1) includes: 2.5   --> obvioulsy false
(100000000000000 to: 500000000000000 by: 100000000000000)
   includes: 200000000000000  --> true as before, I just put some zeros
behind, so what?
(100000000000000 to: 500000000000000 by: 100000000000000)
   includes: 250000000000000  --> true! what? yes, try it yourself!

I'm attaching a version that fixes this problem and the previous one,
but perhaps introduces new failing cases, please someone (less asleep
than me) review it.

German Morales
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IntervalInclusionFix-gm.cs.gz
Type: application/octet-stream
Size: 290 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20040617/4d6c3461/IntervalInclusionFix-gm.cs.obj