Mantis - Squeak
|Viewing Issue Advanced Details|
|ID:||Category:||Severity:||Reproducibility:||Date Submitted:||Last Update:|
|7180||Collections||minor||always||09-09-08 20:16||04-18-10 22:05|
|ETA:||none||Fixed in Version:||trunk|
|Summary:||0007180: Interval method indexOf: / includes: incomplete fix in squeak3.10|
Some patches from 0001602 has been harvested in 3.10 image.
However, as clearly stated in 0001603 by german morales, and further reported and explained by me at 0006455 and 0001602, the patch is not complete:
For example, take the proof from German Morales:
((100 to: 500 by: 100)
indexOf: 250) = 0.
does work as expected.
Now append twelve zeros to the numbers, that's essentially the same test, say expressed in nanometer instead of kilometer:
self assert: ((100000000000000 to: 500000000000000 by: 100000000000000)
indexOf: 250000000000000) = 0.
The later fails because of the intention to do the test with fuzzyness.
1) Fuzzyness should not apply to exact arithmetic.
2) Fuzzyness should be corrected in case of Float (see example in 0006455).
In order to ease the hard job of harvesters, notably concerning the handling of BUG status, I have to open a new issue.
|Steps To Reproduce:|
Another problem seems that 0001603 has not been harvested.
Consequently, Interval>>indexOf: and Interval>>includes: won't agree on the inclusion of an element.
Note that correction proposed by German Morales at 0001603 is still not complete, as illustrated in 0006455. This is why I further uploaded some more patches/tests.
Two more things I do not like about fuzzy Float test:
1) It is not general enough: the fuzzy threshold is arbitrary and vain.
1a) It is arbitrary, because it is not to the Kernel to decide if 3 or 12
figures or whatever should be tested, this is application dependent.
1b) It is vain because I can construct some Interval that won't even includes
it's own elements (See note in 0001602), though the noble fuzziness efforts.
2) It is not general enough:
why not make a fuzzy inclusion tests for some other kind of Collection?
My opinion is that, since not general enough, we should not bother with fuzzyness in the Kernel.
We should either warn the user in Interval comment: USE WITH INTERVAL OF FLOAT AT YOUR OWN RISKS, and let him implement his own application-tailored fuzzyness.
Or we should provide some message passing some arbitrary fuzzy threshold argument.
In the later case, a default implementation using a default threshold would be acceptable eventually.
Whatever my opinion, the least would be to implement fuzzyness correctly.
Links to tests and patchs will be in following notes.