[
https://issues.apache.org/jira/browse/MAHOUT-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789274#action_12789274
]
Jake Mannix commented on MAHOUT-208:
------------------------------------
bq. 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.
I'll own Matrix and Vector if nobody else really has serious plans for it.
MAHOUT-205 is something which needs to come soon, so we can make a
hadoop-independent linar package, with a separate interface to Hadoop, and then
a (couple of) fully parallel Matrix implementation(s), as well as the whole
incorporation of Colt primitives.
bq. But for purposes here: fixing this right now means recomputing the length
on each set() operation.
No! Far too costly. Just invalidate the cache (set lengthNorm to -1, or set a
boolean), because maybe nobody will ever call lengthNorm() on this Vector
again, so why recompute it? Just leave it lazily for the lengthNorm() call.
> 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.
