[
https://issues.apache.org/jira/browse/MAHOUT-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782064#action_12782064
]
Grant Ingersoll commented on MAHOUT-207:
----------------------------------------
Aren't we loosing some of the benefits of SparseVector with this explicit set
to zero stuff (by having to call equivalent)? I've wondered in the past how a
Sparse implementation should handle something like setQuick(i, 0). One
approach is to set it, but the other is to ignore it and possibly remove any
previous nonzero entry, right? Seems like tradeoffs w/ both.
> AbstractVector.hashCode() should not care about the order of iteration over
> elements
> ------------------------------------------------------------------------------------
>
> Key: MAHOUT-207
> URL: https://issues.apache.org/jira/browse/MAHOUT-207
> Project: Mahout
> Issue Type: Bug
> Components: Matrix
> Affects Versions: 0.2
> Environment: all
> Reporter: Jake Mannix
> Assignee: Grant Ingersoll
> Fix For: 0.3
>
> Attachments: MAHOUT-207.patch
>
>
> As was discussed in MAHOUT-165, hashCode can be implemented simply like this:
> {code}
> public int hashCode() {
> final int prime = 31;
> int result = prime + ((name == null) ? 0 : name.hashCode());
> result = prime * result + size();
> Iterator<Element> iter = iterateNonZero();
> while (iter.hasNext()) {
> Element ele = iter.next();
> long v = Double.doubleToLongBits(ele.get());
> result += (ele.index() * (int)(v^(v>>32)));
> }
> return result;
> }
> {code}
> which obviates the need to sort the elements in the case of a random access
> hash-based implementation. Also, (ele.index() * (int)(v^(v>>32)) ) == 0 when
> v = Double.doubleToLongBits(0d), which avoids the wrong hashCode() for sparse
> vectors which have zero elements returned from the iterateNonZero() iterator.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
