Javadoc
Gets the hash code for this Coord; does not use the standard "auto-complete" style of hash that most IDEs will
generate, but instead uses a highly-specific technique based on
Lathe32RNG's random int generation, which
also has two independent ints it uses like a Coord's x and y. Unlike Lathe32RNG, this uses only bitwise
operations (not even addition). This guarantees it will behave correctly on GWT (Lathe32RNG uses an alternate
source file on GWT). It also manages to get extremely low collision rates under many circumstances, and very
frequently manages to avoid colliding on more than 25% of Coords (making the load factor of most hash-based
collections fine at a default of 0.75) while often having 0 collisions with some data sets.
For reference, this was tested on several rectangular sections of Coords of varying density, with sizes from 64
to 512 for x and y separately. On a total of 7,830,980 Coords, an older hashCode() this used got 2,159,553
collisions (27.6% rate), the previous similar hashCode() this used got 1,514,191 collisions (19.3% rate), a naive
java.util.Objects#hash(Object...) approach on x and y got 6,163,604 collisions (78.7% rate), and this
method gets 179,922 collisions (2.3% rate). A perfect general hashCode isn't possible, but for the common usage
of Coords (usually x and y are no greater than 511 and are rarely negative, etc.) we can do better than
return x * 31 + y; (which is close to the high-collision Objects.hash way).
This changed at least five times in SquidLib's history. In general, you shouldn't rely on hashCodes to stay the
same across platforms and versions, whether for the JDK or this library. SquidLib (tries to) never depend on the
unpredictable ordering of some hash-based collections like HashSet and HashMap, instead using its own
OrderedSet and
OrderedMap; if you use the ordered kinds, then the only things that matter about
this hash code are that it's fast (it's fast enough), it's cross-platform compatible (this version avoids using
long values, which are slow on GWT, and is carefully written to behave the same on GWT as desktop) and that it
doesn't collide often (which is now much more accurate than in earlier versions of this method).