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

Reply via email to