[ https://issues.apache.org/jira/browse/MAHOUT-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760893#action_12760893 ]
Sean Owen commented on MAHOUT-165: ---------------------------------- It's a good, important question and one I think needs attention too. (I think there used to be even a 4th such method!) equals() is tricky here since if you define equals() to include only the numeric values in the vector (which is reasonable) then you have some transitivity problems. A named vector may equals some non-named Vector implementation may equal some other named vector with different name, which implies the two named vectors with different names are equal. I believe I and conventional wisdom favor defining equals() more strictly then to avoid surprises. Therefore I would implement equals() as a call to strictEquivalence() -- in fact, would remove that method and make it the implementation of equals(). (In fact, equals() *must* take account of name or else it is inconsistent with hashCode()). equivalent() then stands on its own as a usefully different method, but I don't think it necessarily should be static, for consistency. Also, equals() can then use equivalent() to check that aspect of equality rather than duplicating it. I think if we take these steps, IMHO this aspect makes much more sense and is more correct. > Using better primitives hash for sparse vector for performance gains > -------------------------------------------------------------------- > > Key: MAHOUT-165 > URL: https://issues.apache.org/jira/browse/MAHOUT-165 > Project: Mahout > Issue Type: Improvement > Components: Matrix > Affects Versions: 0.2 > Reporter: Shashikant Kore > Assignee: Grant Ingersoll > Fix For: 0.2 > > Attachments: colt.jar, mahout-165-trove.patch, MAHOUT-165.patch, > mahout-165.patch > > > In SparseVector, we need primitives hash map for index and values. The > present implementation of this hash map is not as efficient as some of the > other implementations in non-Apache projects. > In an experiment, I found that, for get/set operations, the primitive hash of > Colt performance an order of magnitude better than OrderedIntDoubleMapping. > For iteration it is 2x slower, though. > Using Colt in Sparsevector improved performance of canopy generation. For an > experimental dataset, the current implementation takes 50 minutes. Using > Colt, reduces this duration to 19-20 minutes. That's 60% reduction in the > delay. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.