For this reason, it���s better to multiply successive fields by a constant (e.g. shifting left by 2) before XORing them into the hash.�� But then, for objects with lots of fields, the later ones are lot completely, because they are multiplied by a number so large that they are out of the range of the hash.
> On 2 Oct 2017, at 16:37 , Sean P. DeNigris <sean@clipperadams.com> wrote:
>
> 2. #hash
>�� �� �� ��^ var1 hash bitXor: (var2 hash bitXor: var3 hash)
> Is this implementation always safe? It's what I usually hand roll based on
> what I've seen, but Andres Valloud wrote a whole (large) book on hashing, so
> I've always wondered if I was missing something���
If you read Andres book (which is hard, because he won���t make it available online), you will learn that it���s better to
take the order of the instance variables into account.�� #bitXor: is commutative, so it of course ignores order.
In other words, if you have a Point with x and y fields, then 3@9 and 9@3 will have the same hash.
For this reason, it���s better to multiply successive fields by a constant (e.g. shifting left by 2) before XORing them into the hash.�� But then, for objects with lots of fields, the later ones are lot completely, because they are multiplied by a number so large that they are out of the range of the hash.
One can avoid this by using a circular shift to implement the multiply.
All of this was, I thought, implemented in a #hashCombine: method, but I can���t find it in my image.�� Maybe some other Smalltalk ...