On Mon, Jan 07, 2019 at 01:36:10PM -0600, Chris Muller wrote:
> >> > > Name: Kernel-eem.1198
> >> > > Author: eem
> >> > > Time: 24 November 2018, 1:44:47.526422 pm
> >> > > UUID: 100137c4-2514-4b7f-9064-3dcdfe7d8cc9
> >> > > Ancestors: Kernel-eem.1197
> >> > >
> >> > > Redefine LargePositiveInteger hash for compatibility between 32-bit
> >> > > and 64-bit systems.
> >>
> >> Shouldn't the condition should be  ^self digitLength <= 4, instead of 8?
> >
> >
> > Of c course not.  It should be that all integers of 64-bits or less are their rowen hashes.
> >>
> >>
> >> See?
> >>
> >> 32-bit image
> >>    1073741824 hash =    230045764
> >>
> >> 64-bit image
> >>    1073741824 hash  = 1073741824
> >
> >
> > No.  You must be using an un-updated image.  Here's what I get:
> >
> > Smalltalk wordSize 4
> > (2 raisedTo: 63) hash = (2 raisedTo: 63) true
> > (SmallInteger maxVal + 1) hash = (SmallInteger maxVal + 1) true
> >
> >
> > Smalltalk wordSize 8
> > (2 raisedTo: 63) hash = (2 raisedTo: 63) true
> > (SmallInteger maxVal + 1) hash = (SmallInteger maxVal + 1) true
> 
> Whew!  You're right, and I knew I wasn't running an updated image, I
> thought I could read and understand such little code while watching
> some NFL playoff game, but I misread it.  :/   Sorry.
> 
> >> I must be missing something.  I can't believe we didn't notice this
> >> and went into trunk before asking this question...
> >
> >
> > Um, please.  I /did/ ask the question, I /did/ test.  I /do know/ that the idea is for integers of 64-bits or less be their own hashes.  Your result clearly indicates that you're using some erroneous configuration.
> 
> My question was directed at Dave and his question, not you (e.g.,
> going in trunk and THEN asking about hash).  But, I can see how you
> thought that by my not inlining properly, sorry.  I put a TON of hours
> into testing UTCDateAndtime over the holidays.  I had to.

Thanks Chris, the testing has been very helpful.

Here is what I said a couple of weeks ago prior to moving the updates to trunk
(http://lists.squeakfoundation.org/pipermail/squeak-dev/2018-December/200994.html):

> Once moved to trunk, there will be eight failing tests in Chronology-Tests. 
> Each of these represents an issue that I think should be addressed in 
> discussion on the squeak-dev list.

Of the eight failing tests that I mentioned, two were for the hash function,
and that is what I was following up on in this thread. I wanted to make sure
that I was not overlooking anything before I updated the tests to match the
new hash function.

As far as I can there is no problem with the hashing now, aside from the
fact that I neglected to do a HashedCollection rehashAll (this still needs
to be done). So the unit tests are updated to match the hash changes, and
those two tests are now green.

But there are still five test failures left to discuss, so more to follow :-)

Dave