Mailing-List: contact dev-help@mahout.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@mahout.apache.org
Received-SPF: pass (nike.apache.org: domain of robin.anil@gmail.com designates
 209.85.220.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <JIRA.12644457.1366841133405.219388.1366841237347@arcas>
References: <JIRA.12644457.1366841133405@arcas>
 <JIRA.12644457.1366841133405.219388.1366841237347@arcas>
From: Robin Anil <robin.anil@gmail.com>
Date: Wed, 24 Apr 2013 17:24:50 -0500
Message-ID: 
 <CAB+3LJ=qBZwhv_h3f9QvowjXSxO7OONE4toB8KDrUwobt4JZmg@mail.gmail.com>
Subject: Re: [jira] [Created] (MAHOUT-1197) AbstractVector#cross is only
 appropriately efficient for dense vectors
To: Mahout-Dev <dev@mahout.apache.org>
Content-Type: multipart/alternative; boundary=bcaec50162e360475b04db22c6f1

--bcaec50162e360475b04db22c6f1
Content-Type: text/plain; charset=UTF-8

I second. Kill everything thats not used. Dan's assign work will improve
the speed of assignRow. But I can imagine there are even more smarter way
to do this for sparse vectors


On Wed, Apr 24, 2013 at 5:07 PM, Jake Mannix (JIRA) <jira@apache.org> wrote:

> Jake Mannix created MAHOUT-1197:
> -----------------------------------
>
>              Summary: AbstractVector#cross is only appropriately efficient
> for dense vectors
>                  Key: MAHOUT-1197
>                  URL: https://issues.apache.org/jira/browse/MAHOUT-1197
>              Project: Mahout
>           Issue Type: Bug
>           Components: Math
>     Affects Versions: 0.6
>             Reporter: Jake Mannix
>              Fix For: 0.8
>
>
> Nobody overrides this implementation:
> [code]
>   @Override
>   public Matrix cross(Vector other) {
>     Matrix result = matrixLike(size, other.size());
>     for (int row = 0; row < size; row++) {
>       result.assignRow(row, other.times(getQuick(row)));
>     }
>     return result;
>   }
> [code]
>
> I think you can imagine what kind of performance this has on sparse
> vectors (k non-zeroes) with high cardinality (N) - scales as O(N^2) instead
> of O(k^2).
>
> I think the right approach is to *not* implement this in AbstractVector at
> all, and force concrete implementations to properly implement it
> performantly.
>
> Alternatively, killing this method entirely might be appropriate.  If
> anyone was using it (and uses sparse vectors), they'd have complained about
> this by now.
>
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA
> administrators
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>

--bcaec50162e360475b04db22c6f1--