[BUG] arithmetic comparison flaw

Sorry to feed the list, but previous subject of this message was dumb.
So i forward it with a new subject and a little correction (8 instead of 7).

----------  Message transmis  ----------

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 that a and b are not equal.

Nicolas

---------------------------------------------

Try this one:

  | a b c |
  a := 16rFFFFFFFFFFFFF810 / 16r1000000000000.
  b := 16rFFFFFFFFFFFFF801 / 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 (16rFFFFFFFFFFFFF800 / 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

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 !

---

iFRANCE exprimez-vous !