[squeak-dev] #= ==> #hash issues
Tim Olson
tim.olson.mail at gmail.com
Thu Nov 15 13:44:01 UTC 2018
Interval >> size does the correct thing with the stop value, so maybe Interval >> = could use:
isInterval and:
[start = anInterval start and:
[step = anInterval step and:
[self size = anInterval size]]]
— tim
> On Nov 2, 2018, at 12:53 PM, Louis LaBrunda <Lou at Keystone-Software.com> wrote:
>
> Hi Chris,
>
> I know about and understand everything you have said about the spec and the way #= and #hast should work and relate to
> each other. My problem with VA Smalltalks implementation of #= is that it doesn't consider what an interval is and how
> it is used and therefor what equals should mean. I would interpret two intervals being equal if they span the same
> range and not worry about how they got there. In the case where the increment (by) is an integer the start and end
> values map down to integers and if those integers are the same in two intervals then the intervals span the same range
> and should be considered equal. Any program using those intervals would expect them to work the same. In VA Smalltalk
> they would work the same but you can't tell that with #=.
>
> I have no problem with VA's hash based collections, they work the way they should given the way #hash and #= work. But
> from a higher level, if I put a bunch of intervals in a Set and only wanted one entry for each range spanned, I would be
> out of luck and probably confused as to why. Sure, this is Smalltalk and there are ways around this, if you know you
> need to work around it. One could always add a method to intervals to "fix" the start and end values if the increment
> is an integer.
>
> I have heard from Instantiations and they plan to leave well enough alone at this point, since the #= method has been
> this way since 1996. They are concerned that changing #= may break existing user code. I doubt it but I understand the
> concern.
>
> Lou
>
>
> On Fri, 2 Nov 2018 10:01:38 -0700, Chris Cunningham <cunningham.cb at gmail.com> wrote:
>
>> All of that said, I too find the VA troubling a bit in this case. I rely
>> on this (0 to: 1) = (0 to: 5/3) being true. VA not supporting is limits
>> cross-dialect portability, although I don't (personally) use VA, other
>> folks at work do and we do occasionally share code.
>>
>> However, this implementation is internally consistent and obeys the = and
>> hash rule in this case. Its just not what I would want.
>>
>> -cbc
>>
>> On Fri, Nov 2, 2018 at 9:52 AM Chris Cunningham <cunningham.cb at gmail.com>
>> wrote:
>>
>>> Hi Louis,
>>> On Fri, Nov 2, 2018 at 9:12 AM Louis LaBrunda <Lou at keystone-software.com>
>>> wrote:
>>>
>>>> Hi Chris,
>>>>
>>>> On Fri, 2 Nov 2018 07:44:00 -0700, Chris Cunningham <
>>>> cunningham.cb at gmail.com> wrote:
>>>>
>>>>> ParcPlace-Digitalk VSE 3.1 (roughly 1999):
>>>>>
>>>>> (0 to: 1) = (0 to: 5/3). "true"
>>>>> (0 to: 1) hash = (0 to: 5/3) hash. "true"
>>>>>
>>>>> So, ancient VSE and current VisualWorks are consistent, and agree on
>>>> where
>>>>> they want to be. This is also the direction I want to take Squeak.
>>>>> VA is also consistent, but #= doesn't match any other Smalltalk varient
>>>> that we've looked at.
>>>>> Squeak, Pharo, Dolphin all currently have the same answer, but are not
>>>>> consistent.
>>>>
>>>>> Interesting indeed.
>>>>
>>>> I have been talking to the VA Smalltalk guys about this and they are
>>>> thinking about it but haven't decided what to do
>>>> yet. It turns out that the way collections (like Set) that use #hash in
>>>> VA Smalltalk work, because of the #= test
>>>> failing for intervals that cover the same range and have the same hash,
>>>> that it overrides the equal hash value and adds
>>>> the interval to the collection. I find this troubling.
>>>>
>>>> Lou
>>>>
>>>
>>> The rules for = and hash are that if two object are #=, then their hash
>>> values have to be equal as well.
>>>
>>> There is no statement about if two objects hashes are the same, what this
>>> means for equality. This, I believe, is intentional.
>>>
>>> The collection objects in (most?all?) smalltalks behave similarly to VA's
>>> - if objects have the same hash but are not equal, then they will both be
>>> in the hashed collection (such as Set). The squeak implementation is
>>> described in Set>>scanFor: . This method also shows why having objects
>>> equal but their hash not equal is so dangerous - if you had two objects
>>> that are supposed to be one and the same and are in fact #= but don't have
>>> the same hash, they can both show up in a Set together, or as keys in a
>>> Dictionary together, which breaks what we would expect.
>>>
>>> But getting back to VA's collection issue that you have issues with - they
>>> are undoubtedly doing something similar in their collections that we do in
>>> Squeak, which is what is expected (although not necessarily obvious).
>>>
>>> A long time ago, I took advantage of this and just hard-coded the hash for
>>> some of my classes to 1. This actually did work, but is a horrible (I mean
>>> HORRIBLE) idea - it really, really slows down the system when you have more
>>> than a couple instances of an object, but it does work.
>>>
>>> -cbc
>>>
>>>
>>>>
>>>>
>>>>> thanks,
>>>>> cbc
>>>>>
>>>>> On Thu, Nov 1, 2018 at 5:40 AM Louis LaBrunda <Lou at keystone-software.com
>>>>>
>>>>> wrote:
>>>>>
>>>>>> Hi Benoit,
>>>>>>
>>>>>> On the latest version of VA Smalltalk:
>>>>>>
>>>>>> VA Smalltalk V9.1 (32-bit); Image: 9.1 [413]
>>>>>> VM Timestamp: 4.0, 10/01/18 (100)
>>>>>>
>>>>>> I see:
>>>>>>
>>>>>> (0 to: 1) = (0 to: 5/3). "false"
>>>>>> (0 to: 1) hash = (0 to: 5/3) hash. "true"
>>>>>>
>>>>>> Very interesting.
>>>>>>
>>>>>> Lou
>>>>>>
>>>>>>
>>>>>> On Thu, 1 Nov 2018 02:40:00 +0000 (UTC), Benoit St-Jean via Squeak-dev
>>>> <
>>>>>> squeak-dev at lists.squeakfoundation.org> wrote:
>>>>>>
>>>>>>> Interesting!
>>>>>>>
>>>>>>> As a comparison:
>>>>>>> Squeak 5.2
>>>>>>> (0 to: 1) = (0 to: 5/3). "true"(0 to: 1) hash = (0 to: 5/3) hash.
>>>> "false"
>>>>>>> Dolphin 7(0 to: 1) = (0 to: 5/3). "true"(0 to: 1) hash = (0 to: 5/3)
>>>>>> hash. "false"
>>>>>>> VisualWorks 8.1.1(0 to: 1) = (0 to: 5/3). "true"
>>>>>>> (0 to: 1) hash = (0 to: 5/3) hash. "true"
>>>>>>> Pharo 5.0(0 to: 1) = (0 to: 5/3). "true"
>>>>>>> (0 to: 1) hash = (0 to: 5/3) hash. "false"
>>>>>>>
>>>>>>> I don't have VAST installed on the PC I'm using right now. I'd be
>>>>>> curious to see how other Smalltalk and/or GemStone handle this? So far
>>>>>> (according to what I could test, only VW is right (according to the
>>>> ANSI
>>>>>> standard and just plain logic!)
>>>>>>>
>>>>>>> I wonder how much code relies on this "behavior" out there!
>>>>>>> But the ANSI Smalltalk draft is very clear on this (revision 1.9, page
>>>>>> 53,
>>>> http://wiki.squeak.org/squeak/uploads/172/standard_v1_9-indexed.pdf):
>>>>>>> "If the value of receiver = comparand is true then the receiver and
>>>>>> comparand *must* have equivalent hash values."
>>>>>>> That's what I always thought (or was taught or even read in the Blue
>>>>>> Book). Was this something that was changed at some point???
>>>>>>>
>>>>>>> ----------------
>>>>>>> Benoît St-Jean
>>>>>>> Yahoo! Messenger: bstjean
>>>>>>> Twitter: @BenLeChialeux
>>>>>>> Pinterest: benoitstjean
>>>>>>> Instagram: Chef_Benito
>>>>>>> IRC: lamneth
>>>>>>> Blogue: endormitoire.wordpress.com
>>>>>>> "A standpoint is an intellectual horizon of radius zero". (A.
>>>> Einstein)
>>>>>> --
>>>>>> Louis LaBrunda
>>>>>> Keystone Software Corp.
>>>>>> SkypeMe callto://PhotonDemon
>>>>>>
>>>>>>
>>>>>>
>>>> --
>>>> Louis LaBrunda
>>>> Keystone Software Corp.
>>>> SkypeMe callto://PhotonDemon
>>>>
>>>>
>>>>
> --
> Louis LaBrunda
> Keystone Software Corp.
> SkypeMe callto://PhotonDemon
>
>
More information about the Squeak-dev
mailing list
|