Float>>nan
Locked
 
|
Hi,
I have a strange bug: Float nan = Float nan -> false It seem that the primitive for Float>>= is broken. Mth |
|
|
> 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 |
|
|
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 > |
|
|
On 08/09/07, Mathieu Suen <[hidden email]> wrote:
> Ok any reason for that? > > Mth > So that eg: 0 * Float infinity = (0 * Float infinity negated) -> false |
|
|
In reply to this post by Mathieu SUEN
> 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" <[hidden email]> To: "The general-purpose Squeak developers list" <[hidden email]> 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 >> > > |
When are 2 CompiledMethods = [incl: Float>>nan]
|
|
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" <[hidden email]> > To: "The general-purpose Squeak developers list" > <[hidden email]> > 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 >>> >> >> > > > |
Re: When are 2 CompiledMethods = [incl: Float>>nan]
|
|
2007/9/8, Klaus D. Witzel <[hidden email]>:
> 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 :) How can you normally end up with a NaN literal? (Without messing with the compiler, modifying literal arrays or stuff like that). Cheers Philippe > 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" <[hidden email]> > > To: "The general-purpose Squeak developers list" > > <[hidden email]> > > 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 > >>> > >> > >> > > > > > > > > > > |
Re: When are 2 CompiledMethods = [incl: Float>>nan]
|
|
On Sat, 08 Sep 2007 20:00:32 +0200, Philippe Marschall wrote:
> 2007/9/8, Klaus D. Witzel: >> 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 :) > > How can you normally end up with a NaN literal? (Without messing with > the compiler, modifying literal arrays or stuff like that). Float>>#nan "Answer the canonical value used to represent Not-A-Number" ^ NaN /Klaus > Cheers > Philippe > >> 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" >> <[hidden email]> >> > To: "The general-purpose Squeak developers list" >> > <[hidden email]> >> > 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 >> >>> >> >> >> >> >> > >> > >> > >> >> >> >> > > |
Re: When are 2 CompiledMethods = [incl: Float>>nan]
|
|
In reply to this post by Klaus D. Witzel
Hi Klaus -
Revert Association>>= to what it used to be and everything will be fine (Association>>= is really, really badly broken; it causes problems all over the places and this is one of them). Cheers, - Andreas Klaus D. Witzel wrote: > 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" <[hidden email]> >> To: "The general-purpose Squeak developers list" >> <[hidden email]> >> 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 >>>> >>> >>> >> >> >> > > > > |
Re: When are 2 CompiledMethods = [incl: Float>>nan]
|
|
Hi Andreas,
on Sun, 09 Sep 2007 11:26:58 +0200, you wrote: > Hi Klaus - > > Revert Association>>= to what it used to be and everything will be fine > (Association>>= is really, really badly broken; it causes problems all > over the places and this is one of them). That's a very, very good one, thanks for reminding us of that open issue. Since the compiler machinery (BytecodeGenerator) already uses #literalEqual: and I want Decompiler to use the same comparision for literals, it'll be easy to put #literalEqual: into Association without touching its current #= implementation. In a later step it's perhaps possible to really, really revert #= in Association. Thanks again. /Klaus > Cheers, > - Andreas > > Klaus D. Witzel wrote: >> 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" <[hidden email]> >>> To: "The general-purpose Squeak developers list" >>> <[hidden email]> >>> 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 >>>>> >>>> >>>> >>> >>> >>> >> > > > |
Re: When are 2 CompiledMethods = [incl: Float>>nan]
|
|
In reply to this post by Andreas.Raab
+1 on reverting Association>>=
- Bert - On Sep 9, 2007, at 11:26 , Andreas Raab wrote: > Hi Klaus - > > Revert Association>>= to what it used to be and everything will be > fine (Association>>= is really, really badly broken; it causes > problems all over the places and this is one of them). > > Cheers, > - Andreas > > Klaus D. Witzel wrote: >> 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" >>> <[hidden email]> >>> To: "The general-purpose Squeak developers list" <squeak- >>> [hidden email]> >>> 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 >>>>> >>>> >>>> >>> >>> >>> > > |
Asscociation equality (was: Re: When are 2 CompiledMethods = [incl: Float>>nan])
|
|
In reply to this post by Klaus D. Witzel
Klaus D. Witzel wrote:
> on Sun, 09 Sep 2007 11:26:58 +0200, you wrote: >> Revert Association>>= to what it used to be and everything will be >> fine (Association>>= is really, really badly broken; it causes >> problems all over the places and this is one of them). > > That's a very, very good one, thanks for reminding us of that open issue. > > Since the compiler machinery (BytecodeGenerator) already uses > #literalEqual: and I want Decompiler to use the same comparision for > literals, it'll be easy to put #literalEqual: into Association without > touching its current #= implementation. In a later step it's perhaps > possible to really, really revert #= in Association. I only wish I knew *why* this got changed in the first place. Both, #hash and #= have Marcus' initials on it - can someone perhaps ask him why that change was needed or desirable? I'm afraid there may be some non-obvious users of that change but since I can't track down exactly where this happened I really don't know where to even start looking. Cheers, - Andreas |
Re: Asscociation equality (was: Re: When are 2 CompiledMethods = [incl: Float>>nan])
|
|
Hi Andreas,
the addition of Association>>#hash seems to date back to 3.7; haven't found it in 3.6. If you have a maschine with some spare time (I put my Notebook's CPU in slow motion mode), you might want to look at MessageTally spyOn: [Unicode compileAllFrom: Unicode] The example was choosen because there Association>>#hash in call site Dictionary>>#scanFor: bites the CPU and so MessageTally has something to report about. But #bindingOf: (=> #associationAt:) seems to be fast enough to *not* appear in that report (may vary per CPU). The above is just about the #hash part, will instrument my Goya VM and search for effective call sites of Association>>#= some time during the week. (cc'ed Marcus) /Klaus On Tue, 11 Sep 2007 07:36:56 +0200, Andreas wrote: > Klaus D. Witzel wrote: >> on Sun, 09 Sep 2007 11:26:58 +0200, you wrote: >>> Revert Association>>= to what it used to be and everything will be >>> fine (Association>>= is really, really badly broken; it causes >>> problems all over the places and this is one of them). >> That's a very, very good one, thanks for reminding us of that open >> issue. >> Since the compiler machinery (BytecodeGenerator) already uses >> #literalEqual: and I want Decompiler to use the same comparision for >> literals, it'll be easy to put #literalEqual: into Association without >> touching its current #= implementation. In a later step it's perhaps >> possible to really, really revert #= in Association. > > I only wish I knew *why* this got changed in the first place. Both, > #hash and #= have Marcus' initials on it - can someone perhaps ask him > why that change was needed or desirable? I'm afraid there may be some > non-obvious users of that change but since I can't track down exactly > where this happened I really don't know where to even start looking. > > Cheers, > - Andreas > > |
Re: Asscociation equality (was: Re: When are 2 CompiledMethods = [incl: Float>>nan])
|
|
In reply to this post by Andreas.Raab
Is there a Mantis entry for this issue? It has been discussed (but not
resolved) in several prior threads, but now I cannot find any record of the discussion. Dave On Mon, Sep 10, 2007 at 10:36:56PM -0700, Andreas Raab wrote: > Klaus D. Witzel wrote: > >on Sun, 09 Sep 2007 11:26:58 +0200, you wrote: > >>Revert Association>>= to what it used to be and everything will be > >>fine (Association>>= is really, really badly broken; it causes > >>problems all over the places and this is one of them). > > > >That's a very, very good one, thanks for reminding us of that open issue. > > > >Since the compiler machinery (BytecodeGenerator) already uses > >#literalEqual: and I want Decompiler to use the same comparision for > >literals, it'll be easy to put #literalEqual: into Association without > >touching its current #= implementation. In a later step it's perhaps > >possible to really, really revert #= in Association. > > I only wish I knew *why* this got changed in the first place. Both, > #hash and #= have Marcus' initials on it - can someone perhaps ask him > why that change was needed or desirable? I'm afraid there may be some > non-obvious users of that change but since I can't track down exactly > where this happened I really don't know where to even start looking. > > Cheers, > - Andreas |
Re: Asscociation equality (was: Re: When are 2 CompiledMethods = [incl: Float>>nan])
|
|
In reply to this post by Klaus D. Witzel
For name/assoc binding there was nothing which seems to depend on
Association>>#=, say when doing Morph compileAllFrom: Morph except when Dictionary>>#scanFor: is used (for storing bindings). But these (bindings) are by name, not by value, so there seems to be no need for treating them with #=. Only #scanFor: is reported by Goya to do Association>>#= (and all I did run was browsers and other tools and #compileAllFrom:, in stock images). Another observation (which might/not have something to do with Association>>#=) is Association allSubInstances select: [:assoc | (assoc key isKindOf: Association) or: [assoc value isKindOf: Association]] In 3.7/3.8 there are two class vars of CompiledMethod which are associations of associations, namely TempNameCache and BlockNodeCache (ignoring the ->->'s of the VB-Regex package which is not in 3.9). Can someone tell the class var refs for TempNameCache and BlockNodeCache in 3.8 (stock #6665), here it barks because of problems with source code access ... strange. In 3.9 TempNameCache disappeared (mantis turns up two entries on search string TempNameCache) but BlockNodeCache's still in 3.9, albeit unused and with value nil->nil. Since class builder doesn't like to remove BlockNodeCache the following sent it to limbo CompiledMethod classPool removeKey: #BlockNodeCache BTW google knows about - http://www.google.com/search?q=Squeak+BlockNodeCache but Mantis doesn't turn up entries when searching for BlockNodeCache. Will do more search for call sites with Association>>#= in 3.9, later. Hints/ideas on what to look at, except perhaps compilation/name binding, would help. TIA. (cc'ed Marcus) /Klaus On Tue, 11 Sep 2007 09:40:17 +0200, I wrote: > Hi Andreas, > > the addition of Association>>#hash seems to date back to 3.7; haven't > found it in 3.6. > > If you have a maschine with some spare time (I put my Notebook's CPU in > slow motion mode), you might want to look at > > MessageTally spyOn: [Unicode compileAllFrom: Unicode] > > The example was choosen because there Association>>#hash in call site > Dictionary>>#scanFor: bites the CPU and so MessageTally has something to > report about. But #bindingOf: (=> #associationAt:) seems to be fast > enough to *not* appear in that report (may vary per CPU). > > The above is just about the #hash part, will instrument my Goya VM and > search for effective call sites of Association>>#= some time during the > week. > > (cc'ed Marcus) > > /Klaus > > On Tue, 11 Sep 2007 07:36:56 +0200, Andreas wrote: > >> Klaus D. Witzel wrote: >>> on Sun, 09 Sep 2007 11:26:58 +0200, you wrote: >>>> Revert Association>>= to what it used to be and everything will be >>>> fine (Association>>= is really, really badly broken; it causes >>>> problems all over the places and this is one of them). >>> That's a very, very good one, thanks for reminding us of that open >>> issue. >>> Since the compiler machinery (BytecodeGenerator) already uses >>> #literalEqual: and I want Decompiler to use the same comparision for >>> literals, it'll be easy to put #literalEqual: into Association without >>> touching its current #= implementation. In a later step it's perhaps >>> possible to really, really revert #= in Association. >> >> I only wish I knew *why* this got changed in the first place. Both, >> #hash and #= have Marcus' initials on it - can someone perhaps ask him >> why that change was needed or desirable? I'm afraid there may be some >> non-obvious users of that change but since I can't track down exactly >> where this happened I really don't know where to even start looking. >> >> Cheers, >> - Andreas >> >> > > > > |
Re: When are 2 CompiledMethods = [incl: Float>>nan]
|
|
In reply to this post by Andreas.Raab
Andreas Raab wrote:
> Hi Klaus - > > Revert Association>>= to what it used to be and everything will be fine > (Association>>= is really, really badly broken; it causes problems all > over the places and this is one of them). Just for the record, here is how I implemented Association>>#= in GNU Smalltalk to avoid this precise problem (though I don't exclude it introduces others): = anAssociation "Answer whether the association's key and value are the same as anAssociation's, or false if anAssociation is not an Association. As a special case, identical values are considered equal even if #= returns false (as is the case for NaN floating-point values)." self class == anAssociation class ifFalse: [ ^false ]. self key = anAssociation key ifFalse: [ ^false ]. self value == anAssociation value ifTrue: [ ^true ]. ^self value = anAssociation value Paolo |
Re: Asscociation equality (was: Re: When are 2 CompiledMethods = [incl: Float>>nan])
|
|
In reply to this post by Andreas.Raab
On 12.09.2007, at 23:04, stephane ducasse wrote: > > > Begin forwarded message: > >> From: Andreas Raab <[hidden email]> >> Date: 11 septembre 2007 07:36:56 HAEC >> To: The general-purpose Squeak developers list <[hidden email] >> > >> Cc: "The New Compiler, AST, IRBuilder, Closures..." <[hidden email] >> > >> Subject: Asscociation equality (was: Re: When are 2 CompiledMethods >> = [incl: Float>>nan]) >> Reply-To: The general-purpose Squeak developers list <[hidden email] >> > >> >> Klaus D. Witzel wrote: >>> on Sun, 09 Sep 2007 11:26:58 +0200, you wrote: >>>> Revert Association>>= to what it used to be and everything will >>>> be fine (Association>>= is really, really badly broken; it causes >>>> problems all over the places and this is one of them). >>> That's a very, very good one, thanks for reminding us of that open >>> issue. >>> Since the compiler machinery (BytecodeGenerator) already uses >>> #literalEqual: and I want Decompiler to use the same comparision >>> for literals, it'll be easy to put #literalEqual: into Association >>> without touching its current #= implementation. In a later step >>> it's perhaps possible to really, really revert #= in Association. >> >> I only wish I knew *why* this got changed in the first place. Both, >> #hash and #= have Marcus' initials on it - can someone perhaps ask >> him why that change was needed or desirable? I'm afraid there may >> be some non-obvious users of that change but since I can't track >> down exactly where this happened I really don't know where to even >> start looking. >> >> This change came from the time when I played with AOStA. I ported it from VisualWorks, and it uses actually association as keys in Dictionaries somewhere. (That took a while to find why that did not work....). So I changed it in my development image. Then I thought that this is stange, to have (1->2) to be equal to (1- >7) and submitted the changeset to the BFAV bag then. It was reviewed (not by me), and added (not by me) and is in the image since 3.7 or 3.8. And in VisualWorks this is really defined like this: (1->2) = (1->3) --> false = anAssociation "Answer whether the receiver is equal to the argument." ^super = anAssociation and: [self value = anAssociation value] So I am at leat not completely alone with having thought that this is the way it should be. Marcus |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |