[
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.