You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mahout.apache.org by Robin Anil <ro...@apache.org> on 2013/04/20 19:18:33 UTC
Re: Review Request: MAHOUT-1192 [2]: Speed up Vector Operations
Minor variance +-5% is seen in JVM, so I usually dont pay much attention to
those. Try to kill all active cpu using processes before running these. I
am going to patch your diff in to get a before after benchmark on my laptop.
------
Robin Anil
On Sat, Apr 20, 2013 at 11:44 AM, Dan Filimon
<da...@gmail.com>wrote:
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10669/
> Review request for mahout, Ted Dunning, Sebastian Schelter, and Robin
> Anil.
> By Dan Filimon.
>
> *Updated April 20, 2013, 4:44 p.m.*
> Description
>
> This patch contains code cleaning up AbstractVector and making the operations as fast as possible while still having a high level interface.
>
> The main changes are in AbstractVector as well as new methods in DoubleDoubleFunction.
>
> Testing
>
> The vectors test pass but it's likely that the patch in it's current state is broken as other, unrelated tests (BallKMeans...) are failing.
> Also, my Hadoop conf is broken so I didn't run all the core tests. Anyone?
>
> I can't seem to find the bug, so _please_ have a closer look. It's still a work in progress.
>
> The benchmarks seem comparable (although there are some jarring diferences – Minkowski distance seems a lot slower in new-dan-1 than old-trunk-2). It may be however that this is just variance due to the load of the machine at the time. I'm having trouble interpreting the benchmarks in general, so anyone who could give me a hand is more than welcome.
>
> Diffs
>
> - math/src/main/java/org/apache/mahout/math/AbstractMatrix.java
> (e12aa38)
> - math/src/main/java/org/apache/mahout/math/AbstractVector.java
> (090aa7a)
> - math/src/main/java/org/apache/mahout/math/Centroid.java (0c42196)
> - math/src/main/java/org/apache/mahout/math/ConstantVector.java
> (51d67d4)
> - math/src/main/java/org/apache/mahout/math/DelegatingVector.java
> (12220d4)
> - math/src/main/java/org/apache/mahout/math/DenseVector.java (41c356b)
> - math/src/main/java/org/apache/mahout/math/FileBasedSparseBinaryMatrix.java
> (094003b)
> - math/src/main/java/org/apache/mahout/math/MatrixSlice.java (7f79c96)
> - math/src/main/java/org/apache/mahout/math/MatrixVectorView.java
> (af70727)
> - math/src/main/java/org/apache/mahout/math/NamedVector.java (4b7a41d)
> - math/src/main/java/org/apache/mahout/math/OrderedIntDoubleMapping.java
> (650d82d)
> - math/src/main/java/org/apache/mahout/math/PermutedVectorView.java
> (d1ea93a)
> - math/src/main/java/org/apache/mahout/math/RandomAccessSparseVector.java
> (6f85692)
> - math/src/main/java/org/apache/mahout/math/SequentialAccessSparseVector.java
> (21982f9)
> - math/src/main/java/org/apache/mahout/math/Vector.java (2f8b417)
> - math/src/main/java/org/apache/mahout/math/VectorView.java (add2a60)
> - math/src/main/java/org/apache/mahout/math/WeightedVector.java
> (06fbd05)
> - math/src/main/java/org/apache/mahout/math/function/DoubleDoubleFunction.java
> (82b350a)
> - math/src/main/java/org/apache/mahout/math/function/Functions.java
> (eb2e42f)
> - math/src/main/java/org/apache/mahout/math/function/PlusMult.java
> (60587b1)
> - math/src/main/java/org/apache/mahout/math/function/TimesFunction.java
> (8ab0bb1)
> - math/src/main/java/org/apache/mahout/math/jet/math/Constants.java
> (53535d6)
> - math/src/test/java/org/apache/mahout/math/AbstractVectorTest.java
> (2b11199)
> - math/src/test/java/org/apache/mahout/math/TestSequentialAccessSparseVector.java
> (5fbcdd0)
> - math/src/test/java/org/apache/mahout/math/VectorTest.java (d6d554b)
>
> View Diff <https://reviews.apache.org/r/10669/diff/>
>
Re: Review Request: MAHOUT-1192 [2]: Speed up Vector Operations
Posted by Robin Anil <ro...@apache.org>.
Numbers are ops per sec
There are some cluster benchmarks. I don't know who added it. But its baked
as the type column
On Apr 22, 2013 11:51 AM, "Dan Filimon" <da...@gmail.com> wrote:
> In fact the issue I was referring to turns out to be because the very fast
> case was in fact wrong.
> When merging two sparse vectors I wasn't updating the number of mappings
> in the result.
>
> Performance is now better for the more "tuned" vectors.
> I have noticed some random regressions with dense vectors ... this is
> pretty odd. :/
>
> Anyway, can you give me some insight into:
> - what exactly the numbers in the spreadsheet mean?
> - what is the "Cluster" score for some benchmarks? There don't seem to be
> explicit calls to any cluster vectors.
>
> Thanks!
>
>
>
> On Mon, Apr 22, 2013 at 5:24 PM, Robin Anil <ro...@apache.org> wrote:
>
>> Yes every time you replace primitive call you are at the mercy of jit to
>> inline the method. Choose primitive wherever possible to reduce variability
>> On Apr 22, 2013 7:15 AM, "Dan Filimon" <da...@gmail.com>
>> wrote:
>>
>>> Thanks!
>>>
>>> So, I'm running more benchmark and it's a mixed bag. There are
>>> regressions and gains, but what surprises me the most is that after
>>> replacing every "primitive" call with calls to assign/aggregate, the
>>> clustering behaves much worse.
>>>
>>> As in, dozens (literally) of times worse. I'm surprised it's so bad, yet
>>> doesn't show in the benchmarks.
>>> Any ideas why this might be, or what I should look into?
>>>
>>>
>>> On Sat, Apr 20, 2013 at 9:14 PM, Robin Anil <ro...@apache.org>wrote:
>>>
>>>>
>>>> https://docs.google.com/spreadsheet/ccc?key=0AhewTD_ZgznddGFQbWJCQTZXSnFULUYzdURfWDRJQlE#gid=2
>>>>
>>>> Here you go. There are some regressions and some improvements. One of
>>>> the major reasons I think is replacing inline math with foo.apply(). JVM
>>>> might not have optimized it yet. You might be better off but just adding an
>>>> AggregateBenchmark and working on it for your functions before replacing
>>>> entire AbstractVector methods.
>>>>
>>>
>>>
>
Re: Review Request: MAHOUT-1192 [2]: Speed up Vector Operations
Posted by Robin Anil <ro...@apache.org>.
PS, you can modify a constant in the VectorBenchmarks.java to increase time
per benchmark (currently set to 500 milliseconds). To increase the
confidence in the benchmark sample. But for now its fine.
------
Robin Anil
On Mon, Apr 22, 2013 at 12:30 PM, Dan Filimon
<da...@gmail.com>wrote:
> And... they failed. I broke some DistributedRowMatrix tests.
>
>
> On Mon, Apr 22, 2013 at 8:14 PM, Dan Filimon <dangeorge.filimon@gmail.com
> >wrote:
>
> > The tests are still running. I want to make sure they all pass before
> > another round of benchmarks. :)
> >
> >
> > On Mon, Apr 22, 2013 at 8:00 PM, Robin Anil <ro...@apache.org>
> wrote:
> >
> >> Can you update/create a spreadsheet of where you are right now v/s trunk
> >> On Apr 22, 2013 11:51 AM, "Dan Filimon" <da...@gmail.com>
> >> wrote:
> >>
> >>> In fact the issue I was referring to turns out to be because the very
> >>> fast case was in fact wrong.
> >>> When merging two sparse vectors I wasn't updating the number of
> mappings
> >>> in the result.
> >>>
> >>> Performance is now better for the more "tuned" vectors.
> >>> I have noticed some random regressions with dense vectors ... this is
> >>> pretty odd. :/
> >>>
> >>> Anyway, can you give me some insight into:
> >>> - what exactly the numbers in the spreadsheet mean?
> >>> - what is the "Cluster" score for some benchmarks? There don't seem to
> >>> be explicit calls to any cluster vectors.
> >>>
> >>> Thanks!
> >>>
> >>>
> >>>
> >>> On Mon, Apr 22, 2013 at 5:24 PM, Robin Anil <robinanil@apache.org
> >wrote:
> >>>
> >>>> Yes every time you replace primitive call you are at the mercy of jit
> >>>> to inline the method. Choose primitive wherever possible to reduce
> >>>> variability
> >>>> On Apr 22, 2013 7:15 AM, "Dan Filimon" <da...@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> Thanks!
> >>>>>
> >>>>> So, I'm running more benchmark and it's a mixed bag. There are
> >>>>> regressions and gains, but what surprises me the most is that after
> >>>>> replacing every "primitive" call with calls to assign/aggregate, the
> >>>>> clustering behaves much worse.
> >>>>>
> >>>>> As in, dozens (literally) of times worse. I'm surprised it's so bad,
> >>>>> yet doesn't show in the benchmarks.
> >>>>> Any ideas why this might be, or what I should look into?
> >>>>>
> >>>>>
> >>>>> On Sat, Apr 20, 2013 at 9:14 PM, Robin Anil <robinanil@apache.org
> >wrote:
> >>>>>
> >>>>>>
> >>>>>>
> https://docs.google.com/spreadsheet/ccc?key=0AhewTD_ZgznddGFQbWJCQTZXSnFULUYzdURfWDRJQlE#gid=2
> >>>>>>
> >>>>>> Here you go. There are some regressions and some improvements. One
> of
> >>>>>> the major reasons I think is replacing inline math with
> foo.apply(). JVM
> >>>>>> might not have optimized it yet. You might be better off but just
> adding an
> >>>>>> AggregateBenchmark and working on it for your functions before
> replacing
> >>>>>> entire AbstractVector methods.
> >>>>>>
> >>>>>
> >>>>>
> >>>
> >
>
Re: Review Request: MAHOUT-1192 [2]: Speed up Vector Operations
Posted by Dan Filimon <da...@gmail.com>.
And... they failed. I broke some DistributedRowMatrix tests.
On Mon, Apr 22, 2013 at 8:14 PM, Dan Filimon <da...@gmail.com>wrote:
> The tests are still running. I want to make sure they all pass before
> another round of benchmarks. :)
>
>
> On Mon, Apr 22, 2013 at 8:00 PM, Robin Anil <ro...@apache.org> wrote:
>
>> Can you update/create a spreadsheet of where you are right now v/s trunk
>> On Apr 22, 2013 11:51 AM, "Dan Filimon" <da...@gmail.com>
>> wrote:
>>
>>> In fact the issue I was referring to turns out to be because the very
>>> fast case was in fact wrong.
>>> When merging two sparse vectors I wasn't updating the number of mappings
>>> in the result.
>>>
>>> Performance is now better for the more "tuned" vectors.
>>> I have noticed some random regressions with dense vectors ... this is
>>> pretty odd. :/
>>>
>>> Anyway, can you give me some insight into:
>>> - what exactly the numbers in the spreadsheet mean?
>>> - what is the "Cluster" score for some benchmarks? There don't seem to
>>> be explicit calls to any cluster vectors.
>>>
>>> Thanks!
>>>
>>>
>>>
>>> On Mon, Apr 22, 2013 at 5:24 PM, Robin Anil <ro...@apache.org>wrote:
>>>
>>>> Yes every time you replace primitive call you are at the mercy of jit
>>>> to inline the method. Choose primitive wherever possible to reduce
>>>> variability
>>>> On Apr 22, 2013 7:15 AM, "Dan Filimon" <da...@gmail.com>
>>>> wrote:
>>>>
>>>>> Thanks!
>>>>>
>>>>> So, I'm running more benchmark and it's a mixed bag. There are
>>>>> regressions and gains, but what surprises me the most is that after
>>>>> replacing every "primitive" call with calls to assign/aggregate, the
>>>>> clustering behaves much worse.
>>>>>
>>>>> As in, dozens (literally) of times worse. I'm surprised it's so bad,
>>>>> yet doesn't show in the benchmarks.
>>>>> Any ideas why this might be, or what I should look into?
>>>>>
>>>>>
>>>>> On Sat, Apr 20, 2013 at 9:14 PM, Robin Anil <ro...@apache.org>wrote:
>>>>>
>>>>>>
>>>>>> https://docs.google.com/spreadsheet/ccc?key=0AhewTD_ZgznddGFQbWJCQTZXSnFULUYzdURfWDRJQlE#gid=2
>>>>>>
>>>>>> Here you go. There are some regressions and some improvements. One of
>>>>>> the major reasons I think is replacing inline math with foo.apply(). JVM
>>>>>> might not have optimized it yet. You might be better off but just adding an
>>>>>> AggregateBenchmark and working on it for your functions before replacing
>>>>>> entire AbstractVector methods.
>>>>>>
>>>>>
>>>>>
>>>
>
Re: Review Request: MAHOUT-1192 [2]: Speed up Vector Operations
Posted by Dan Filimon <da...@gmail.com>.
The tests are still running. I want to make sure they all pass before
another round of benchmarks. :)
On Mon, Apr 22, 2013 at 8:00 PM, Robin Anil <ro...@apache.org> wrote:
> Can you update/create a spreadsheet of where you are right now v/s trunk
> On Apr 22, 2013 11:51 AM, "Dan Filimon" <da...@gmail.com>
> wrote:
>
>> In fact the issue I was referring to turns out to be because the very
>> fast case was in fact wrong.
>> When merging two sparse vectors I wasn't updating the number of mappings
>> in the result.
>>
>> Performance is now better for the more "tuned" vectors.
>> I have noticed some random regressions with dense vectors ... this is
>> pretty odd. :/
>>
>> Anyway, can you give me some insight into:
>> - what exactly the numbers in the spreadsheet mean?
>> - what is the "Cluster" score for some benchmarks? There don't seem to be
>> explicit calls to any cluster vectors.
>>
>> Thanks!
>>
>>
>>
>> On Mon, Apr 22, 2013 at 5:24 PM, Robin Anil <ro...@apache.org> wrote:
>>
>>> Yes every time you replace primitive call you are at the mercy of jit to
>>> inline the method. Choose primitive wherever possible to reduce variability
>>> On Apr 22, 2013 7:15 AM, "Dan Filimon" <da...@gmail.com>
>>> wrote:
>>>
>>>> Thanks!
>>>>
>>>> So, I'm running more benchmark and it's a mixed bag. There are
>>>> regressions and gains, but what surprises me the most is that after
>>>> replacing every "primitive" call with calls to assign/aggregate, the
>>>> clustering behaves much worse.
>>>>
>>>> As in, dozens (literally) of times worse. I'm surprised it's so bad,
>>>> yet doesn't show in the benchmarks.
>>>> Any ideas why this might be, or what I should look into?
>>>>
>>>>
>>>> On Sat, Apr 20, 2013 at 9:14 PM, Robin Anil <ro...@apache.org>wrote:
>>>>
>>>>>
>>>>> https://docs.google.com/spreadsheet/ccc?key=0AhewTD_ZgznddGFQbWJCQTZXSnFULUYzdURfWDRJQlE#gid=2
>>>>>
>>>>> Here you go. There are some regressions and some improvements. One of
>>>>> the major reasons I think is replacing inline math with foo.apply(). JVM
>>>>> might not have optimized it yet. You might be better off but just adding an
>>>>> AggregateBenchmark and working on it for your functions before replacing
>>>>> entire AbstractVector methods.
>>>>>
>>>>
>>>>
>>
Re: Review Request: MAHOUT-1192 [2]: Speed up Vector Operations
Posted by Robin Anil <ro...@apache.org>.
Can you update/create a spreadsheet of where you are right now v/s trunk
On Apr 22, 2013 11:51 AM, "Dan Filimon" <da...@gmail.com> wrote:
> In fact the issue I was referring to turns out to be because the very fast
> case was in fact wrong.
> When merging two sparse vectors I wasn't updating the number of mappings
> in the result.
>
> Performance is now better for the more "tuned" vectors.
> I have noticed some random regressions with dense vectors ... this is
> pretty odd. :/
>
> Anyway, can you give me some insight into:
> - what exactly the numbers in the spreadsheet mean?
> - what is the "Cluster" score for some benchmarks? There don't seem to be
> explicit calls to any cluster vectors.
>
> Thanks!
>
>
>
> On Mon, Apr 22, 2013 at 5:24 PM, Robin Anil <ro...@apache.org> wrote:
>
>> Yes every time you replace primitive call you are at the mercy of jit to
>> inline the method. Choose primitive wherever possible to reduce variability
>> On Apr 22, 2013 7:15 AM, "Dan Filimon" <da...@gmail.com>
>> wrote:
>>
>>> Thanks!
>>>
>>> So, I'm running more benchmark and it's a mixed bag. There are
>>> regressions and gains, but what surprises me the most is that after
>>> replacing every "primitive" call with calls to assign/aggregate, the
>>> clustering behaves much worse.
>>>
>>> As in, dozens (literally) of times worse. I'm surprised it's so bad, yet
>>> doesn't show in the benchmarks.
>>> Any ideas why this might be, or what I should look into?
>>>
>>>
>>> On Sat, Apr 20, 2013 at 9:14 PM, Robin Anil <ro...@apache.org>wrote:
>>>
>>>>
>>>> https://docs.google.com/spreadsheet/ccc?key=0AhewTD_ZgznddGFQbWJCQTZXSnFULUYzdURfWDRJQlE#gid=2
>>>>
>>>> Here you go. There are some regressions and some improvements. One of
>>>> the major reasons I think is replacing inline math with foo.apply(). JVM
>>>> might not have optimized it yet. You might be better off but just adding an
>>>> AggregateBenchmark and working on it for your functions before replacing
>>>> entire AbstractVector methods.
>>>>
>>>
>>>
>
Re: Review Request: MAHOUT-1192 [2]: Speed up Vector Operations
Posted by Dan Filimon <da...@gmail.com>.
In fact the issue I was referring to turns out to be because the very fast
case was in fact wrong.
When merging two sparse vectors I wasn't updating the number of mappings in
the result.
Performance is now better for the more "tuned" vectors.
I have noticed some random regressions with dense vectors ... this is
pretty odd. :/
Anyway, can you give me some insight into:
- what exactly the numbers in the spreadsheet mean?
- what is the "Cluster" score for some benchmarks? There don't seem to be
explicit calls to any cluster vectors.
Thanks!
On Mon, Apr 22, 2013 at 5:24 PM, Robin Anil <ro...@apache.org> wrote:
> Yes every time you replace primitive call you are at the mercy of jit to
> inline the method. Choose primitive wherever possible to reduce variability
> On Apr 22, 2013 7:15 AM, "Dan Filimon" <da...@gmail.com>
> wrote:
>
>> Thanks!
>>
>> So, I'm running more benchmark and it's a mixed bag. There are
>> regressions and gains, but what surprises me the most is that after
>> replacing every "primitive" call with calls to assign/aggregate, the
>> clustering behaves much worse.
>>
>> As in, dozens (literally) of times worse. I'm surprised it's so bad, yet
>> doesn't show in the benchmarks.
>> Any ideas why this might be, or what I should look into?
>>
>>
>> On Sat, Apr 20, 2013 at 9:14 PM, Robin Anil <ro...@apache.org> wrote:
>>
>>>
>>> https://docs.google.com/spreadsheet/ccc?key=0AhewTD_ZgznddGFQbWJCQTZXSnFULUYzdURfWDRJQlE#gid=2
>>>
>>> Here you go. There are some regressions and some improvements. One of
>>> the major reasons I think is replacing inline math with foo.apply(). JVM
>>> might not have optimized it yet. You might be better off but just adding an
>>> AggregateBenchmark and working on it for your functions before replacing
>>> entire AbstractVector methods.
>>>
>>
>>
Re: Review Request: MAHOUT-1192 [2]: Speed up Vector Operations
Posted by Robin Anil <ro...@apache.org>.
Yes every time you replace primitive call you are at the mercy of jit to
inline the method. Choose primitive wherever possible to reduce variability
On Apr 22, 2013 7:15 AM, "Dan Filimon" <da...@gmail.com> wrote:
> Thanks!
>
> So, I'm running more benchmark and it's a mixed bag. There are regressions
> and gains, but what surprises me the most is that after replacing every
> "primitive" call with calls to assign/aggregate, the clustering behaves
> much worse.
>
> As in, dozens (literally) of times worse. I'm surprised it's so bad, yet
> doesn't show in the benchmarks.
> Any ideas why this might be, or what I should look into?
>
>
> On Sat, Apr 20, 2013 at 9:14 PM, Robin Anil <ro...@apache.org> wrote:
>
>>
>> https://docs.google.com/spreadsheet/ccc?key=0AhewTD_ZgznddGFQbWJCQTZXSnFULUYzdURfWDRJQlE#gid=2
>>
>> Here you go. There are some regressions and some improvements. One of the
>> major reasons I think is replacing inline math with foo.apply(). JVM might
>> not have optimized it yet. You might be better off but just adding an
>> AggregateBenchmark and working on it for your functions before replacing
>> entire AbstractVector methods.
>>
>
>
Re: Review Request: MAHOUT-1192 [2]: Speed up Vector Operations
Posted by Dan Filimon <da...@gmail.com>.
Thanks!
So, I'm running more benchmark and it's a mixed bag. There are regressions
and gains, but what surprises me the most is that after replacing every
"primitive" call with calls to assign/aggregate, the clustering behaves
much worse.
As in, dozens (literally) of times worse. I'm surprised it's so bad, yet
doesn't show in the benchmarks.
Any ideas why this might be, or what I should look into?
On Sat, Apr 20, 2013 at 9:14 PM, Robin Anil <ro...@apache.org> wrote:
>
> https://docs.google.com/spreadsheet/ccc?key=0AhewTD_ZgznddGFQbWJCQTZXSnFULUYzdURfWDRJQlE#gid=2
>
> Here you go. There are some regressions and some improvements. One of the
> major reasons I think is replacing inline math with foo.apply(). JVM might
> not have optimized it yet. You might be better off but just adding an
> AggregateBenchmark and working on it for your functions before replacing
> entire AbstractVector methods.
>
Re: Review Request: MAHOUT-1192 [2]: Speed up Vector Operations
Posted by Robin Anil <ro...@apache.org>.
https://docs.google.com/spreadsheet/ccc?key=0AhewTD_ZgznddGFQbWJCQTZXSnFULUYzdURfWDRJQlE#gid=2
Here you go. There are some regressions and some improvements. One of the
major reasons I think is replacing inline math with foo.apply(). JVM might
not have optimized it yet. You might be better off but just adding an
AggregateBenchmark and working on it for your functions before replacing
entire AbstractVector methods.
Re: Review Request: MAHOUT-1192 [2]: Speed up Vector Operations
Posted by Robin Anil <ro...@apache.org>.
I just checked in a csv string dumper for the benchmarks, it might be easy
for you to import them into spreadsheets easily.
------
Robin Anil
On Sat, Apr 20, 2013 at 12:18 PM, Robin Anil <ro...@apache.org> wrote:
> Minor variance +-5% is seen in JVM, so I usually dont pay much attention
> to those. Try to kill all active cpu using processes before running these.
> I am going to patch your diff in to get a before after benchmark on my
> laptop.
>
> ------
> Robin Anil
>
>
>
> On Sat, Apr 20, 2013 at 11:44 AM, Dan Filimon <dangeorge.filimon@gmail.com
> > wrote:
>
>> This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/10669/
>> Review request for mahout, Ted Dunning, Sebastian Schelter, and Robin
>> Anil.
>> By Dan Filimon.
>>
>> *Updated April 20, 2013, 4:44 p.m.*
>> Description
>>
>> This patch contains code cleaning up AbstractVector and making the operations as fast as possible while still having a high level interface.
>>
>> The main changes are in AbstractVector as well as new methods in DoubleDoubleFunction.
>>
>> Testing
>>
>> The vectors test pass but it's likely that the patch in it's current state is broken as other, unrelated tests (BallKMeans...) are failing.
>> Also, my Hadoop conf is broken so I didn't run all the core tests. Anyone?
>>
>> I can't seem to find the bug, so _please_ have a closer look. It's still a work in progress.
>>
>> The benchmarks seem comparable (although there are some jarring diferences – Minkowski distance seems a lot slower in new-dan-1 than old-trunk-2). It may be however that this is just variance due to the load of the machine at the time. I'm having trouble interpreting the benchmarks in general, so anyone who could give me a hand is more than welcome.
>>
>> Diffs
>>
>> - math/src/main/java/org/apache/mahout/math/AbstractMatrix.java
>> (e12aa38)
>> - math/src/main/java/org/apache/mahout/math/AbstractVector.java
>> (090aa7a)
>> - math/src/main/java/org/apache/mahout/math/Centroid.java (0c42196)
>> - math/src/main/java/org/apache/mahout/math/ConstantVector.java
>> (51d67d4)
>> - math/src/main/java/org/apache/mahout/math/DelegatingVector.java
>> (12220d4)
>> - math/src/main/java/org/apache/mahout/math/DenseVector.java (41c356b)
>> - math/src/main/java/org/apache/mahout/math/FileBasedSparseBinaryMatrix.java
>> (094003b)
>> - math/src/main/java/org/apache/mahout/math/MatrixSlice.java (7f79c96)
>> - math/src/main/java/org/apache/mahout/math/MatrixVectorView.java
>> (af70727)
>> - math/src/main/java/org/apache/mahout/math/NamedVector.java (4b7a41d)
>> - math/src/main/java/org/apache/mahout/math/OrderedIntDoubleMapping.java
>> (650d82d)
>> - math/src/main/java/org/apache/mahout/math/PermutedVectorView.java
>> (d1ea93a)
>> - math/src/main/java/org/apache/mahout/math/RandomAccessSparseVector.java
>> (6f85692)
>> - math/src/main/java/org/apache/mahout/math/SequentialAccessSparseVector.java
>> (21982f9)
>> - math/src/main/java/org/apache/mahout/math/Vector.java (2f8b417)
>> - math/src/main/java/org/apache/mahout/math/VectorView.java (add2a60)
>> - math/src/main/java/org/apache/mahout/math/WeightedVector.java
>> (06fbd05)
>> - math/src/main/java/org/apache/mahout/math/function/DoubleDoubleFunction.java
>> (82b350a)
>> - math/src/main/java/org/apache/mahout/math/function/Functions.java
>> (eb2e42f)
>> - math/src/main/java/org/apache/mahout/math/function/PlusMult.java
>> (60587b1)
>> - math/src/main/java/org/apache/mahout/math/function/TimesFunction.java
>> (8ab0bb1)
>> - math/src/main/java/org/apache/mahout/math/jet/math/Constants.java
>> (53535d6)
>> - math/src/test/java/org/apache/mahout/math/AbstractVectorTest.java
>> (2b11199)
>> - math/src/test/java/org/apache/mahout/math/TestSequentialAccessSparseVector.java
>> (5fbcdd0)
>> - math/src/test/java/org/apache/mahout/math/VectorTest.java (d6d554b)
>>
>> View Diff <https://reviews.apache.org/r/10669/diff/>
>>
>
>