[
https://issues.apache.org/jira/browse/MAHOUT-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789262#action_12789262
]
Sean Owen commented on MAHOUT-208:
----------------------------------
Actually I think you are right that this is the ultimate solution. Many uses of
Vector don't mutate them, and therefore that should be something one can
optimize for by selecting an immutable implementation.
Actually there are a number of issues I'd like to discuss about the Vector
implementation, perhaps sooner than later. Who should I understand to be the
"owner" of Vector? I also ask because we need to understand how the migration
to Colt is going, and who's heading that up.
But for purposes here: fixing this right now means recomputing the length on
each set() operation. That's better than broken code, but is it better than not
caching? If I just took out caching actually would that be good motivation to
refactor Vector?
> 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.
