Bug in Rhino.Geometry.Transform.GetHashCode

It seems that Transform.GetHashCode is buggy, and does not involve all 16 coordinates in its calculation. Attached a Grasshopper model that confirms this. The hash codes for 2D rotations result in two different numbers only :wink:




TransformHashcodeTest.ghx (44.9 KB)

I think what happens is that the number returned is above the maximum or minimum 32-bit integer but you can not get that real value, due to a lazy hashing algorithm like m00 ^ m01 ^ m02 ^ m03 ^ m10 ^ m11 ^ … has a high probability of falling outside the limits of the integer number.

Try your own algorithm like this one where each int means the hash value of each matrix value:

Yep I have already worked around this by implementing my own hashing function, but I still consider this a bug that should get fixed :wink:

Transform.GetHashCode does involve all coordinates. But the algorithm is probably too simple.

Hi @snabela,

I’ll see that this is tuned up.

https://mcneel.myjetbrains.com/youtrack/issue/RH-65150

– Dale

many thanks @dale

RH-65150 is fixed in Rhino 7 Service Release 10 Release Candidate