+1 to what Andreas Valloud (Mr "how to hash in Smalltalk") said. On 31 July 2018 at 10:34, Andres Valloud <avall...@smalltalk.comcastbiz.net> wrote:
> The interval > > 1 to: (10 raisedTo: 100) > > can be created just fine, yet hashing its elements won't compute. > > A generous interpretation of the intent of #=, where any wisp of > equivalence is promoted to full fledged equality, is problematic in the > long run. Here's another one: > > 17/20 = 0.85, therefore (17/20) hash = 0.85 hash > > Never mind there's no floating point value that is equal to 17/20 in the > first place. It just snowballs from there. For instance, should > collections like these be equal? > > (0.0 to: 1.0 by: 0.3) = #(0.0 0.3 0.6 0.9) > > Sometimes it's just better if different things stay different. > > Andres. > > > On 7/30/18 8:27 , Henrik Sperre Johansen wrote: > >> jgfoster wrote >> >>> Werner, >>> >>> I would say that you are right, this is a problem. A (not un-common) >>> source of subtle bugs in Smalltalk is missing this rule that equivalent >>> objects must have the same hash. In GemStone the objects are not >>> equivalent (I’m not arguing that this is right, just that it avoids the >>> problem you identify). >>> >>> I wonder what would happen if the hash comparison were added to the >>> equivalence operator (#’=‘)! >>> >>> James >>> >>> On Jul 30, 2018, at 5:07 AM, werner kassens < >>>> >>> >> wkassens@ >>> >> >> > wrote: >>> >>>> >>>> Hi, >>>> i guess i can subsume almost everything i know about hashes in one >>>> sentence: >>>> it is my understanding that two objects that are equal (obj1=obj2. >>>> -->true) have to have the same hash value (which is used for some >>>> collection types), whereas objects where obj1=obj2 returns false should >>>> have different hash values although it may happen that they have the >>>> same one. >>>> >>>> now here things don't turn out exactly like that: >>>> (1 to:4) = #(1 2 3 4). "true" >>>> (1 to:4)hash = #(1 2 3 4)hash. "false" >>>> well ok, actually these results make - pfffh, in a certain way - sense >>>> to me, but i wonder what arguments the people in the know would use to >>>> defend that result, if i would have another opinion? >>>> werner >>>> >>>> >>>> >>>> >> +1, this is a bug. >> Either Interval >> #hash needs to change*, or the equivalency be broken**. >> >> Fun fact: >> #(1 2 3 4) = #[1 2 3 4] false >> You'd think they might be more similar than an Interval and an Array, or a >> LinkedList containing ValueLinks and an Interval, but no ;) >> >> Cheers, >> Henry >> >> *Interval >> hash >> "Hash is reimplemented because = is implemented. >> Since we are equivalent to other collections of our species, we >> must also >> hash equivalently" >> | hash | >> >> hash := self species hash. >> start to: stop by: step do: [:element | hash := (hash + element >> hash) >> hashMultiply]. >> ^hash >> >> **both ways, which is challenging, if one neither wants to: >> - change species of Interval (which has bad consequences) >> - add hash comparison to sequenceablecollection = (which slows it down >> even >> further) >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> . >> >> >
