Hi,

Math and I discuss comparing two CompiledMethods whether or not they  
represent the same object when compiled from source. This is necessary for  
writing tests for the Decompiler.

One of the obstacles are certainly the methods' literals, in particular  
Float>>#nan which have to be treated equal in the two compared methods,  
regardless of the fact that (Float nan = Float nan) == false :)

Are there other cases which should be considered, for example does someone  
expect that Float>>#closeTo: is used for comparing Float literals of two  
methods? If that's not the case then Float literals other than nan, can be  
compared with good old fashioned #=.

FWIW the two methods could have been compiled by different compilers  
and/or have literals (for example in class vars) created by different  
readers (think of Number#>>readFrom:), makes writing tests for the  
Decompiler not that easy :|

TIA.

/Klaus

On Sat, 08 Sep 2007 17:30:37 +0200, Alejandro F. Reimondo wrote:

>
>> Ok any reason for that?
> Yes. "nan" is not an object (it does not preserve identity),
>  it is something that can be named and that preserve
>  behavior (we can draw/attach an interface for/to it),
>  those properties does not make it an object.
>
> Ale.
>
>
>
> ----- Original Message ----- From: "Mathieu Suen" <mathk.sue at gmail.com>
> To: "The general-purpose Squeak developers list"  
> <squeak-dev at lists.squeakfoundation.org>
> Sent: Saturday, September 08, 2007 9:48 AM
> Subject: Re: Float>>nan
>
>
>> Ok any reason for that?
>>
>> Mth
>>
>>
>>
>> On Sep 8, 2007, at 12:24 PM, Lukas Renggli wrote:
>>
>>>> I have a strange bug:
>>>>
>>>> Float nan = Float nan -> false
>>>
>>> According to the standard NaN is not be equal to anything,  including  
>>> itself.
>>>
>>> Check: http://en.wikipedia.org/wiki/IEEE_754
>>>
>>> Lukas
>>>
>>> -- Lukas Renggli
>>> http://www.lukas-renggli.ch
>>>
>>
>>
>
>
>