Another flaw in arithmetic.
try this one:
| a b |
a := 16rFFFFFFFFFFFFF81.
b := a asDouble.
Array
with: a = b
with: a hash = b hash.
Objects are equal (hem, that's what the implementation tell).
Hash code are not equal.
Be prepared to Set bugs.
The problem is not really in hash.
I would argue again that a and b are not equal.
BTW, my first example is not exact neither, 7 should be replaced by 8.
Nicolas
[hidden email]:
Try this:
| a b c |
a := 16rFFFFFFFFFFFFF710 / 16r1000000000000.
b := 16rFFFFFFFFFFFFF701 / 16r1000000000000.
c := a asFloat.
Array
with: ((Set
new) add: a; add: b; add: c; size)
with: ((Set new) add: c; add: a; add: b; size).
you will get one set of size 2, and one set of size 1.
I argue that i should have one set of size 3, because c machine representation is (16rFFFFFFFFFFFFF700 / 16r1000000000000), neither equal to a nor b.
So where is the mistake ?
I think it is in coercing Fraction to Float or Double.
Float and Double are subsets of Fraction, they are less general (and they are certainly not covering Real numbers, no machine can do that, it is proven that some real numbers do not even have an algorithm that can compute them).
The price for making more efficient arithmetic, but less rigourous is the above bug among others.
Can we tolerate such behavior ?
Nicolas
<a href="http://web.ifrance
.com/">iFRANCE
exprimez-vous !
Locked
