This is a really good point. Clearly we shouldn't be using these as keys except in the IdentityHashTable case.
I do like having equals() be deep equals and even like having equals(double tolerance) in addition. Exact quality is actually more useful than it might seem since integer valued vectors are pretty common when you are counting. On Thu, Feb 23, 2012 at 5:24 PM, Jake Mannix <[email protected]> wrote: > Hey Devs. > > Was prototyping some stuff in Mahout last night, and noticed something > I'm not sure if we've talked about before: because we have equals() for > Vector instances return true iff the numeric values of the vectors are > equal, and we also have a consistent hashCode(), anytime you have > HashMap<Vector, Anything>, all the typical things you think are O(1) are > really O(vector.numNonZeroes()). I tried to look through the codebase and > see where we hang onto maps with vector keys, and we do it sometimes. > Maybe we shouldn't? Most Vectors have identities (clusterId, documentId, > topicId, etc...) which we could normalize away... or maybe we should be > using IdentityHashMap, to ensure you're using strict object identity and > avoid doing this calculation? This could be really slow if these are big > dense vectors, for instance. > > This looks like it could be a really easy place to accidentally add heavy > complexity to things. Do we really want people do be checking > *mathematical* equals() on vectors which have floating point precision? > > -jake >
