mahout-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shashikant Kore (JIRA)" <j...@apache.org>
Subject [jira] Commented: (MAHOUT-208) Vector.getLengthSquared() is dangerously optimized
Date Fri, 11 Dec 2009 08:33:18 GMT

    [ https://issues.apache.org/jira/browse/MAHOUT-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789171#action_12789171
] 

Shashikant Kore commented on MAHOUT-208:
----------------------------------------

It is important to have this caching  to keep the work done on MAHOUT-121 intact. 

Alternative to maintaining caching flag is to use the hashcode of underlying constructs. For
example, in case of SparseVector, we could use OpenIntDoubleHashMap.hashCode() to see if the
cached value is still valid.  In case of DenseVectors, hashcode of arrays can be used.



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


Mime
View raw message