At 13:14 -0500 11/29/99, Jarvis, Robert P. wrote:
The attached change set combines Andrew's changes with Dan's suggestions and runs correctly for the test cases identified, as well as for negative numbers, i.e.
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. (I implemented a version if #includes: that is simply:
includesP: aValue ^ self asArray includes: aValue
and used it for comparison. This IS a precise and accurate solution, though it might run out of memory at inconvenient times and otherwise misbehave when the interval has lots of elements.
Dave _______________________________ David N. Smith IBM T J Watson Research Center Hawthorne, NY _______________________________ Any opinions or recommendations herein are those of the author and not of his employer.
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
This is on a PPC; I would gess that the particular floating point hardware might make a difference.
It shouldn't on any of the micros Squeak is ported to. IEEE754/854 specifies the behavior of these chips, regardless of their makers. The only difference to be had is when an architecture is emulating double-precision using extended-precision. (64-bit floats using an 80-bit base representation). I think this was an option on the Mac68k, but I don't know what SANE did to these calculations.
-John
The PPC does, however, have some interesting instructions, such as its algebraic right shift operator.
squeak-dev@lists.squeakfoundation.org