#= ==> #hash issues

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
29 messages Options
12
cbc
Reply | Threaded
Open this post in threaded view
|

#= ==> #hash issues

cbc
Hi.

I'm slowly (very) working towards crating a usable test for validating for classes where #= is true, #hash will also be true.

Last week, the Date issue showed up.  This week? 
Intervals:
   (0 to: 1) = (0 to: 5/3). "true"
   (0 to: 1) hash = (0 to: 5/3) hash. "false"
CharacterBlock:
   | cb1 cb2 |
   cb1 := (CharacterBlock new stringIndex: 5 text: 'StandardText' asText topLeft: (100@100) extent: (20@20)).
   cb2 := (CharacterBlock new stringIndex: 5 text: 'StandardText' asText topLeft: (200@200) extent: (20@20)).
   cb1 = cb2. "true"
   cb1 hash = cb2 hash. "false"

These were found by comparing a random sampling of instances of classes that implement #= or #hash (or both), and finding which have these deviant properties.  The hard part is figuring out instances that are going to have issues - Date didn't show up in my prototype scanning.  Also most classes don't have instances floating around to compare.

Thanks,
-cbc


Reply | Threaded
Open this post in threaded view
|

Re: #= ==> #hash issues

David T. Lewis
Oh my, it sounds like you are tracking down a likely source of very
obscure intermittent bugs. Bravo.

Dave

On Fri, Oct 26, 2018 at 03:21:20PM -0700, Chris Cunningham wrote:

> Hi.
>
> I'm slowly (very) working towards crating a usable test for validating for
> classes where #= is true, #hash will also be true.
>
> Last week, the Date issue showed up.  This week?
> Intervals:
>    (0 to: 1) = (0 to: 5/3). "true"
>    (0 to: 1) hash = (0 to: 5/3) hash. "false"
> CharacterBlock:
>    | cb1 cb2 |
>    cb1 := (CharacterBlock new stringIndex: 5 text: 'StandardText' asText
> topLeft: (100@100) extent: (20@20)).
>    cb2 := (CharacterBlock new stringIndex: 5 text: 'StandardText' asText
> topLeft: (200@200) extent: (20@20)).
>    cb1 = cb2. "true"
>    cb1 hash = cb2 hash. "false"
>
> These were found by comparing a random sampling of instances of classes
> that implement #= or #hash (or both), and finding which have these deviant
> properties.  The hard part is figuring out instances that are going to have
> issues - Date didn't show up in my prototype scanning.  Also most classes
> don't have instances floating around to compare.
>
> Thanks,
> -cbc

>


cbc
Reply | Threaded
Open this post in threaded view
|

Re: #= ==> #hash issues

cbc


On Fri, Oct 26, 2018 at 4:44 PM David T. Lewis <[hidden email]> wrote:
Oh my, it sounds like you are tracking down a likely source of very
obscure intermittent bugs. Bravo.

Dave

Yes.  

Looking at the latest 5.2b, I find that 0 = 0, but 0 hash does not = 0 hash (for 2 existing instances of LargePositiveInteger). That is odd.  Unfortunately, I can't seem to actually capture the ones that are causing the issue to investigate - the get normalized (or something) to regular 0 integers.

However, while looking at this, I noticed that the fall back code in Integer>>digitCompare: is buggy.

If you evaluate
  1 digitCompare: -1249. "1"
but, if you then comment out "<primitive: 'primDigitCompare' module:'LargeInteger'>" in that method and run it again, you get:
  1 digitCompare: -1249. "-1"

-cbc


Reply | Threaded
Open this post in threaded view
|

Re: #= ==> #hash issues

Nicolas Cellier

Le dim. 28 oct. 2018 à 18:23, Chris Cunningham <[hidden email]> a écrit :


On Fri, Oct 26, 2018 at 4:44 PM David T. Lewis <[hidden email]> wrote:
Oh my, it sounds like you are tracking down a likely source of very
obscure intermittent bugs. Bravo.

Dave

Yes.  

Looking at the latest 5.2b, I find that 0 = 0, but 0 hash does not = 0 hash (for 2 existing instances of LargePositiveInteger). That is odd.  Unfortunately, I can't seem to actually capture the ones that are causing the issue to investigate - the get normalized (or something) to regular 0 integers.

However, while looking at this, I noticed that the fall back code in Integer>>digitCompare: is buggy.

If you evaluate
  1 digitCompare: -1249. "1"
but, if you then comment out "<primitive: 'primDigitCompare' module:'LargeInteger'>" in that method and run it again, you get:
  1 digitCompare: -1249. "-1"

-cbc



cbc
Reply | Threaded
Open this post in threaded view
|

Re: #= ==> #hash issues

cbc


On Sun, Oct 28, 2018 at 2:53 PM Nicolas Cellier <[hidden email]> wrote:

and 
 
Intervals:
   (0 to: 1) = (0 to: 5/3). "true"
   (0 to: 1) hash = (0 to: 5/3) hash. "false"

In the inbox is collections-cbc.810.mcz, which fixes both of these bugs.

You can test them out - #hash still replicates the bugs, while #hashBetterFastArrayCompatible (on Interval) and #hashBetterFastIntervalCompatible (on Array) makes both work.  The later also implements your idea of only testing some of the elements - the first and last 16.

It slows down hash speed of Interval roughly an order of magnitude, though.

If anyone hash ideas I'd be interested. Failing that, I'll ruminate on them for the next several days, and eventually push something in that fixes this (meanwhile moving that package to treated).
-----
Here is the series of 'tests' that I did while working on these with various timings.

{
[(1 to: 100 by: 1) hash] bench.
[(1 to: 100 by: 1) hashBetter] bench.
[(1 to: 100 by: 1) hashBetterAlsoFixBug3380] bench.
[(1 to: 100 by: 1) hashSlowerBetterAlsoFixBug3380] bench.
[(1 to: 100 by: 1) hashFastArrayCompatible] bench.
[(1 to: 100 by: 1) hashBetterFastArrayCompatible] bench.
'---'.
[(1 to: 100.3 by: 1) hash] bench.
[(1 to: 100.3 by: 1) hashBetter] bench.
[(1 to: 100.3 by: 1) hashBetterAlsoFixBug3380] bench.
[(1 to: 100.3 by: 1) hashSlowerBetterAlsoFixBug3380] bench.
[(1 to: 100.3 by: 1) hashFastArrayCompatible] bench.
[(1 to: 100.3 by: 1) hashBetterFastArrayCompatible] bench.
}

{
(0 to: 1) = (0 to: 5/3). 
(0 to: 1) hash = (0 to: 5/3) hash.
(0 to: 1) hashBetter = (0 to: 5/3) hashBetter.
(0 to: 1) hashBetterAlsoFixBug3380 = (0 to: 5/3) hashBetterAlsoFixBug3380.
(0 to: 1) hashSlowerBetterAlsoFixBug3380 = (0 to: 5/3) hashSlowerBetterAlsoFixBug3380.
(0 to: 1) hashFastArrayCompatible = (0 to: 5/3) hashFastArrayCompatible.
(0 to: 1) hashBetterFastArrayCompatible = (0 to: 5/3) hashBetterFastArrayCompatible.
}


{
(1 to: 3) = #(1 2 3).
(1 to: 3) hash = #(1 2 3) hash.
(1 to: 3) hashBetter = #(1 2 3) hash.
(1 to: 3) hashBetterAlsoFixBug3380 = #(1 2 3) hash.
(1 to: 3) hashSlowerBetterAlsoFixBug3380 = #(1 2 3) hash.
(1 to: 3) hashFastArrayCompatible = #(1 2 3) hashFastIntervalCompatible.
(1 to: 3) hashBetterFastArrayCompatible = #(1 2 3) hashBetterFastIntervalCompatible.
}

-cbc


Reply | Threaded
Open this post in threaded view
|

Re: #= ==> #hash issues

Nicolas Cellier
Remonder: this is because interval is used for text selection and/or cursor position. From that POV, 3 to: 2 is not equal to 4 to: 3. From collection POV, they are both an empty collection. I think that i once proposed to distinguish the two usages and introduce a TextInterval for that purpose.

Le lun. 29 oct. 2018 à 01:35, Chris Cunningham <[hidden email]> a écrit :


On Sun, Oct 28, 2018 at 2:53 PM Nicolas Cellier <[hidden email]> wrote:

and 
 
Intervals:
   (0 to: 1) = (0 to: 5/3). "true"
   (0 to: 1) hash = (0 to: 5/3) hash. "false"

In the inbox is collections-cbc.810.mcz, which fixes both of these bugs.

You can test them out - #hash still replicates the bugs, while #hashBetterFastArrayCompatible (on Interval) and #hashBetterFastIntervalCompatible (on Array) makes both work.  The later also implements your idea of only testing some of the elements - the first and last 16.

It slows down hash speed of Interval roughly an order of magnitude, though.

If anyone hash ideas I'd be interested. Failing that, I'll ruminate on them for the next several days, and eventually push something in that fixes this (meanwhile moving that package to treated).
-----
Here is the series of 'tests' that I did while working on these with various timings.

{
[(1 to: 100 by: 1) hash] bench.
[(1 to: 100 by: 1) hashBetter] bench.
[(1 to: 100 by: 1) hashBetterAlsoFixBug3380] bench.
[(1 to: 100 by: 1) hashSlowerBetterAlsoFixBug3380] bench.
[(1 to: 100 by: 1) hashFastArrayCompatible] bench.
[(1 to: 100 by: 1) hashBetterFastArrayCompatible] bench.
'---'.
[(1 to: 100.3 by: 1) hash] bench.
[(1 to: 100.3 by: 1) hashBetter] bench.
[(1 to: 100.3 by: 1) hashBetterAlsoFixBug3380] bench.
[(1 to: 100.3 by: 1) hashSlowerBetterAlsoFixBug3380] bench.
[(1 to: 100.3 by: 1) hashFastArrayCompatible] bench.
[(1 to: 100.3 by: 1) hashBetterFastArrayCompatible] bench.
}

{
(0 to: 1) = (0 to: 5/3). 
(0 to: 1) hash = (0 to: 5/3) hash.
(0 to: 1) hashBetter = (0 to: 5/3) hashBetter.
(0 to: 1) hashBetterAlsoFixBug3380 = (0 to: 5/3) hashBetterAlsoFixBug3380.
(0 to: 1) hashSlowerBetterAlsoFixBug3380 = (0 to: 5/3) hashSlowerBetterAlsoFixBug3380.
(0 to: 1) hashFastArrayCompatible = (0 to: 5/3) hashFastArrayCompatible.
(0 to: 1) hashBetterFastArrayCompatible = (0 to: 5/3) hashBetterFastArrayCompatible.
}


{
(1 to: 3) = #(1 2 3).
(1 to: 3) hash = #(1 2 3) hash.
(1 to: 3) hashBetter = #(1 2 3) hash.
(1 to: 3) hashBetterAlsoFixBug3380 = #(1 2 3) hash.
(1 to: 3) hashSlowerBetterAlsoFixBug3380 = #(1 2 3) hash.
(1 to: 3) hashFastArrayCompatible = #(1 2 3) hashFastIntervalCompatible.
(1 to: 3) hashBetterFastArrayCompatible = #(1 2 3) hashBetterFastIntervalCompatible.
}

-cbc



Reply | Threaded
Open this post in threaded view
|

Re: #= ==> #hash issues

Squeak - Dev mailing list
In reply to this post by cbc
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)



Reply | Threaded
Open this post in threaded view
|

#= ==> #hash issues

Louis LaBrunda
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 <[hidden email]> 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


cbc
Reply | Threaded
Open this post in threaded view
|

Re: #= ==> #hash issues

cbc
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.

thanks,
cbc

On Thu, Nov 1, 2018 at 5:40 AM Louis LaBrunda <[hidden email]> 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 <[hidden email]> 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 <a href="callto://PhotonDemon" target="_blank">callto://PhotonDemon




Reply | Threaded
Open this post in threaded view
|

#= ==> #hash issues

Louis LaBrunda
Hi Chris,

On Fri, 2 Nov 2018 07:44:00 -0700, Chris Cunningham <[hidden email]> 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


>thanks,
>cbc
>
>On Thu, Nov 1, 2018 at 5:40 AM Louis LaBrunda <[hidden email]>
>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 <
>> [hidden email]> 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


cbc
Reply | Threaded
Open this post in threaded view
|

Re: #= ==> #hash issues

cbc
Hi Louis,
On Fri, Nov 2, 2018 at 9:12 AM Louis LaBrunda <[hidden email]> wrote:
Hi Chris,

On Fri, 2 Nov 2018 07:44:00 -0700, Chris Cunningham <[hidden email]> 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 <[hidden email]>
>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 <
>> [hidden email]> 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 <a href="callto://PhotonDemon" target="_blank">callto://PhotonDemon
>>
>>
>>
--
Louis LaBrunda
Keystone Software Corp.
SkypeMe <a href="callto://PhotonDemon" target="_blank">callto://PhotonDemon




cbc
Reply | Threaded
Open this post in threaded view
|

Re: #= ==> #hash issues

cbc
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 <[hidden email]> wrote:
Hi Louis,
On Fri, Nov 2, 2018 at 9:12 AM Louis LaBrunda <[hidden email]> wrote:
Hi Chris,

On Fri, 2 Nov 2018 07:44:00 -0700, Chris Cunningham <[hidden email]> 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 <[hidden email]>
>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 <
>> [hidden email]> 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 <a href="callto://PhotonDemon" target="_blank">callto://PhotonDemon
>>
>>
>>
--
Louis LaBrunda
Keystone Software Corp.
SkypeMe <a href="callto://PhotonDemon" target="_blank">callto://PhotonDemon




Reply | Threaded
Open this post in threaded view
|

#= ==> #hash issues

Louis LaBrunda
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 <[hidden email]> 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 <[hidden email]>
>wrote:
>
>> Hi Louis,
>> On Fri, Nov 2, 2018 at 9:12 AM Louis LaBrunda <[hidden email]>
>> wrote:
>>
>>> Hi Chris,
>>>
>>> On Fri, 2 Nov 2018 07:44:00 -0700, Chris Cunningham <
>>> [hidden email]> 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 <[hidden email]
>>> >
>>> >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
>>> <
>>> >> [hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: #= ==> #hash issues

Tim Olson
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> wrote:
>>
>>> Hi Louis,
>>> On Fri, Nov 2, 2018 at 9:12 AM Louis LaBrunda <[hidden email]>
>>> wrote:
>>>
>>>> Hi Chris,
>>>>
>>>> On Fri, 2 Nov 2018 07:44:00 -0700, Chris Cunningham <
>>>> [hidden email]> 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 <[hidden email]
>>>>>
>>>>> 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
>>>> <
>>>>>> [hidden email]> 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
>
>


Reply | Threaded
Open this post in threaded view
|

#= ==> #hash issues

Louis LaBrunda
Hi Tim,

After thoroughly discussing this with the VA Smalltalk guys I have concluded that the developer should be responsible
for creating intervals that have equal ranges that compare equal.  For example intervals with mixed integers and real
values can have the same range but don't compare equal.  If comparing equal is desired, the values should be made to
make that work.

Lou


On Thu, 15 Nov 2018 07:44:01 -0600, Tim Olson <[hidden email]> wrote:

>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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>> wrote:
>>>
>>>> Hi Louis,
>>>> On Fri, Nov 2, 2018 at 9:12 AM Louis LaBrunda <[hidden email]>
>>>> wrote:
>>>>
>>>>> Hi Chris,
>>>>>
>>>>> On Fri, 2 Nov 2018 07:44:00 -0700, Chris Cunningham <
>>>>> [hidden email]> 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 <[hidden email]
>>>>>>
>>>>>> 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
>>>>> <
>>>>>>> [hidden email]> 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
>>
>>
>
>
--
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon


Reply | Threaded
Open this post in threaded view
|

Re: #= ==> #hash issues

Eliot Miranda-2
In reply to this post by Squeak - Dev mailing list
Hi Benoît,

On Oct 31, 2018, at 7:40 PM, Benoit St-Jean via Squeak-dev <[hidden email]> 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???

Nothing was changed.  It’s simply people not realizing there is a bug there.  Hence the value of Chris’ tests.

----------------
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)




Reply | Threaded
Open this post in threaded view
|

Re: #= ==> #hash issues

Eliot Miranda-2
In reply to this post by Tim Olson
> On Nov 15, 2018, at 5:44 AM, Tim Olson <[hidden email]> wrote:
>
> 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]]]

The current implementation is correct; it is effectively the same as
your's but has some obvious optimizations.  Two intervals are equal if
they have the same sequence of elements, no matter how they are
written.  Here is is:

= anObject

    ^ self == anObject
        ifTrue: [true]
        ifFalse: [anObject isInterval
            ifTrue: [start = anObject first
                    and: [step = anObject increment
                    and: [self last = anObject last]]]
            ifFalse: [super = anObject]]

which I would have written
= anObject
    ^self == anObject
     or: [anObject isInterval
                ifFalse: [super = anObject]
                ifTrue:
                    [start = anObject first
                     and: [step = anObject increment
                     and: [self last = anObject last]]]]

The issue is with hash which accesses stop directly instead of last.
If hash read

hash
    "Hash is reimplemented because = is implemented."

    ^(((start hash bitShift: 2)
        bitOr: self last hash)
        bitShift: 1)
        bitOr: self size

(i.e. "bitOr: stop hash)" => "bitOr: self last hash)"
then things will be fine.  And most common intervals hash will not change.



>
>    — tim
>
>> On Nov 2, 2018, at 12:53 PM, Louis LaBrunda <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>> wrote:
>>>
>>>> Hi Louis,
>>>> On Fri, Nov 2, 2018 at 9:12 AM Louis LaBrunda <[hidden email]>
>>>> wrote:
>>>>
>>>>> Hi Chris,
>>>>>
>>>>> On Fri, 2 Nov 2018 07:44:00 -0700, Chris Cunningham <
>>>>> [hidden email]> 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 <[hidden email]
>>>>>>
>>>>>> 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
>>>>> <
>>>>>>> [hidden email]> 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
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: #= ==> #hash issues

Eliot Miranda-2
In reply to this post by Louis LaBrunda
> On Nov 15, 2018, at 5:55 AM, Louis LaBrunda <[hidden email]> wrote:
>
> Hi Tim,
>
> After thoroughly discussing this with the VA Smalltalk guys I have concluded that the developer should be responsible
> for creating intervals that have equal ranges that compare equal.  For example intervals with mixed integers and real
> values can have the same range but don't compare equal.  If comparing equal is desired, the values should be made to
> make that work.

IMO that’s a cop out.  An implementation which compares two intervals
as equal if their elements are equal makes perfect sense and is easy
to implement.  All that’s needed is that the implementation access
“self last” instead of “stop”.

Implementing newHash as one that uses self last in place of stop then
in my image


| insts s |
insts := Interval allInstances.
{ insts size. s := (insts select: [:i| i hash ~= i newHash]) size. s *
100.0 / insts size } #(3267 0 0.0)

So there's minimal risk in breaking anything simply redefining hash (I
would also reformat #= as per my suggestion ;-) ).

>
> Lou
>
>
>> On Thu, 15 Nov 2018 07:44:01 -0600, Tim Olson <[hidden email]> wrote:
>>
>> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>> wrote:
>>>>
>>>>> Hi Louis,
>>>>> On Fri, Nov 2, 2018 at 9:12 AM Louis LaBrunda <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> Hi Chris,
>>>>>>
>>>>>> On Fri, 2 Nov 2018 07:44:00 -0700, Chris Cunningham <
>>>>>> [hidden email]> 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 <[hidden email]
>>>>>>>
>>>>>>> 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
>>>>>> <
>>>>>>>> [hidden email]> 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
>>>
>>>
>>
>>
> --
> Louis LaBrunda
> Keystone Software Corp.
> SkypeMe callto://PhotonDemon
>
>

Reply | Threaded
Open this post in threaded view
|

#= ==> #hash issues

Louis LaBrunda
Hi Eliot,

I really shouldn't speak for Instantiations but since I brought them into this conversation I will say this:

(0 to: 1) = (0 to: 5/3). "false"
(0 to: 1) hash = (0 to: 5/3) hash. "true"

The comparison of the intervals answers false.  I argued strenuously that two intervals that cover the same range should
compare as equal.  Unfortunately the ANSI standard is I think ambiguous on this point.  It says that if two things
compare equal their hashes should be equal but here the two intervals don't compare equal.  The VA Smalltalk code has
been this way for over 20 years.  Changing it could impact an unknown amount of customer code.  I eventually concluded
that even though the ranges were equal the objects were not and that their definition of equal was as valid as any
other.  If this came up 20+ years ago, maybe they could be convinced to change their definition.  Now I agree with them,
it is too late and too dangerous.

Since this is Smalltalk, if one is really interested in intervals that cover the same range comparing equal, there are
simple ways to make that work.  Yes, moving code from Squeal to VA Smalltalk would need a little love but probably not
much.

Lou

On Thu, 15 Nov 2018 07:50:31 -0800, Eliot Miranda <[hidden email]> wrote:

>> On Nov 15, 2018, at 5:55 AM, Louis LaBrunda <[hidden email]> wrote:
>>
>> Hi Tim,
>>
>> After thoroughly discussing this with the VA Smalltalk guys I have concluded that the developer should be responsible
>> for creating intervals that have equal ranges that compare equal.  For example intervals with mixed integers and real
>> values can have the same range but don't compare equal.  If comparing equal is desired, the values should be made to
>> make that work.
>
>IMO that’s a cop out.  An implementation which compares two intervals
>as equal if their elements are equal makes perfect sense and is easy
>to implement.  All that’s needed is that the implementation access
>“self last” instead of “stop”.
>
>Implementing newHash as one that uses self last in place of stop then
>in my image
>
>
>| insts s |
>insts := Interval allInstances.
>{ insts size. s := (insts select: [:i| i hash ~= i newHash]) size. s *
>100.0 / insts size } #(3267 0 0.0)
>
>So there's minimal risk in breaking anything simply redefining hash (I
>would also reformat #= as per my suggestion ;-) ).
>
>>
>> Lou
>>
>>
>>> On Thu, 15 Nov 2018 07:44:01 -0600, Tim Olson <[hidden email]> wrote:
>>>
>>> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> Hi Louis,
>>>>>> On Fri, Nov 2, 2018 at 9:12 AM Louis LaBrunda <[hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Chris,
>>>>>>>
>>>>>>> On Fri, 2 Nov 2018 07:44:00 -0700, Chris Cunningham <
>>>>>>> [hidden email]> 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 <[hidden email]
>>>>>>>>
>>>>>>>> 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
>>>>>>> <
>>>>>>>>> [hidden email]> 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
>>>>
>>>>
>>>
>>>
>> --
>> Louis LaBrunda
>> Keystone Software Corp.
>> SkypeMe callto://PhotonDemon
>>
>>
>
--
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon


Reply | Threaded
Open this post in threaded view
|

Re: #= ==> #hash issues

Bert Freudenberg
Isn't this extremely simple to fix?

#= is implemented in terms of start, step, and last.

So why not implement #hash as

^(start hash bitXor: step hash) bitXor: self last hash

Then in the postscript do a 

HashedCollection rehashAll

and that should be it, right?

I did a quick check using

Dictionary allInstances select: [ :dict | dict keys anySatisfy: #isInterval]

and the system seems fine after that.

- Bert -


12