[squeakdev] 32 vs 64 bits and large integer hash
Nicolas Cellier
nicolas.cellier.aka.nice at gmail.com
Wed Nov 21 20:23:40 UTC 2018
+1
And brilliant hack! though the former code explains by itself, the later
not so much without a comment.
Le mer. 21 nov. 2018 à 19:46, Eliot Miranda <eliot.miranda at gmail.com> a
écrit :
> Hi All,
>
> right now we have the following definition of
> Large(Positive)Integer>>hash:
>
> hash
> ^ByteArray hashBytes: self startingWith: self species hash
>
> which means that for all integers outside of the 32bit SmallInteger range
> (2 ^ 30 to 2 ^ 30  1), the 32bit system and the 64bit system answer
> different values for hash.
>
> e.g. in 64 bits: (2 raisedTo: 30) hash 1073741824
> but in 32 bits: (2 raisedTo: 30) hash 230045764
>
> This is unsatisfactory. I propose changing Large(Positive)Integer>>hash to
>
> hash
> ^self digitLength <= 8
> ifTrue: [self]
> ifFalse: [ByteArray hashBytes: self startingWith: self species hash]
>
>
> P.S. Note that this will not break Float hash, which is defined as
>
> Float>>hash
> "Hash is reimplemented because = is implemented. Both words of the float
> are used. (The bitShift:'s ensure that the intermediate results do not
> become a large integer.) Care is taken to answer same hash as an equal
> Integer."
>
> (self isFinite and: [self fractionPart = 0.0]) ifTrue: [^self truncated
> hash].
> ^ ((self basicAt: 1) bitShift: 4) +
> ((self basicAt: 2) bitShift: 4)
>
> P.P.S. I *think* that "(self isFinite and: [self fractionPart = 0.0])" is
> equivalent to "self  self = self fractionPart" ;)
>
> _,,,^..^,,,_
> best, Eliot
>
>
 next part 
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeakdev/attachments/20181121/56cb5d71/attachment.html>
More information about the Squeakdev
mailing list
