[
https://issues.apache.org/jira/browse/MAHOUT-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789217#action_12789217
]
Jake Mannix commented on MAHOUT-208:
------------------------------------
So the strategy is just "be careful" (what I did in decomposer), not "separate
out the mutating iterators from the immutable ones", right? Personally I'd be
fine if we decided to go the slightly easier route for now, and only did
caching on immutable vectors (make a new subclass, and move the caching down
into that), because this actually covers most of both Shashi and my main use
cases. Of course, there are probably many more, so "doing it right" and
keeping a properly invalidated cache even for mutable vectors is desirable in
the long run.
> Vector.getLengthSquared() is dangerously optimized
> --------------------------------------------------
>
> Key: MAHOUT-208
> URL: https://issues.apache.org/jira/browse/MAHOUT-208
> Project: Mahout
> Issue Type: Bug
> Components: Matrix
> Affects Versions: 0.1
> Environment: all
> Reporter: Jake Mannix
> Assignee: Sean Owen
> Fix For: 0.3
>
>
> SparseVector and DenseVector both cache the value of lengthSquared, so that
> subsequent calls to it get the cached value. Great, except the cache is
> never cleared - calls to set/setQuick or assign or anything, all leave the
> cached value unchanged.
> Mutating method calls should set lengthNorm to -1 so that the cache is
> cleared.
> This could be a really nasty bug if hit.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
