Hi Andreas,

I agree we should answer false to equality test, unless exact arithmetic.
Note that (1/3) asFloat asFraction = (1/3) answer false since asTrueFraction 
is used, 
but (1/2) asFloat asFraction = (1/2) is true, and that is exactly how we like 
it.

I think we should change coercion algorithm for equality test relying on the 
asTrueFraction, but not touch + * - / since it would break lot of code.
This could be something like:

Float>>adaptToFraction: rcvr andSend: selector
    ^selector = #=
        ifTrue: [[rcvr = self asTrueFraction]
            "have to handle NaN and Infinity"
            on: Error do: [:exc | exc return: false]]
        ifFalse: [rcvr asFloat perform: selector with: self].

same in Fraction>>adpatToFloat: rcvr andSend: selector

This does also apply to < > <= >= ~= (some are inherited and need not being 
handled, some must be handled the same way as =, except error handling block 
because we cannot compare to NaN and should raise an error...).
So we have to complexify above method a bit. If it becomes too complex, we'll 
have to use more specialized selectors.

Note that same stuff is to be done for Float/Integer coercion:
  | a b c |
  a := 16rFFFFFFFFFFFFF81.
  b := 16rFFFFFFFFFFFFF82.
  c := a asFloat.
  {a = b.
   a = c.
   b = c.}

Maybe we can also expect advices from other Smalltalkers, and make various 
dialect response more uniform on such a Kernel subject.
I went on vwnc mailing list with these, but no answer yet.

Agree ?

Nicolas

Le Mardi 28 Mars 2006 12:45, Andreas Raab a écrit :
> Wow. Great catch. Clearly, this is broken. I think we need to change
> this coercion to something that deals with the issue properly (e.g.,
> responding false to the comparison in question). Any ideas how to fix that?
>
> Cheers,
>    - Andreas
>