Re: Does SSVD supports eigendecomposition of non-symmetric & non-positive-semidefinitive matrix better than Lanczos?
Thanks a lot Sebastian, Ted and Dmitriy, I'll try Giraph for a performance benchmark. You are right, power iteration is just the most simple form of Lanczos, it shouldn't be in the scope. On Tue 18 Feb 2014 03:59:57 AM EST, Sebastian Schelter wrote: You can also use giraph for a superfast PageRank implementation. Giraph even runs on standard hadoop clusters. Pagerank is usually computed by power iteration, which is much simpler than lanczos or ssvd and only gives the eigenvector associated with the largest eigenvalue. Am 18.02.2014 09:33 schrieb "Peng Cheng" : Really? I guess PageRank in mahout was removed due to inherited network bottleneck of mapreduce. But I didn't know MLlib has the implementation. Is mllib implementation based on Lanczos or SSVD? Just curious... On 17/02/2014 11:11 PM, Dmitriy Lyubimov wrote: I bet page rank in mllib in spark finds stationary distribution much faster. On Feb 17, 2014 1:33 PM, "peng" wrote: Agreed, and this is the case where Lanczos algorithm is obsolete. My point is: if SSVD is unable to find the eigenvector of asymmetric matrix (this is a common formulation of PageRank, and some random walks, and many other things), then we still have to rely on large-scale Lanczos algorithm. On Mon 17 Feb 2014 04:25:16 PM EST, Ted Dunning wrote: For the symmetric case, SVD is eigen decomposition. On Mon, Feb 17, 2014 at 1:12 PM, peng wrote: If SSVD is not designed for such eigenvector problem. Then I would vote for retaining the Lanczos algorithm. However, I would like to see the opposite case, I have tested both algorithms on symmetric case and SSVD is much faster and more accurate than its competitor. Yours Peng On Wed 12 Feb 2014 03:25:47 PM EST, peng wrote: In PageRank I'm afraid I have no other option than eigenvector \lambda, but not singular vector u & v:) The PageRank in Mahout was removed with other graph-based algorithm. On Tue 11 Feb 2014 06:34:17 PM EST, Ted Dunning wrote: SSVD is very probably better than Lanczos for any large decomposition. That said, it does SVD, not eigen decomposition which means that the question of symmetrical matrices or positive definiteness doesn't much matter. Do you really need eigen-decomposition? On Tue, Feb 11, 2014 at 2:55 PM, peng wrote: Just asking for possible replacement of our Lanczos-based PageRank implementation. - Peng
Re: Does SSVD supports eigendecomposition of non-symmetric & non-positive-semidefinitive matrix better than Lanczos?
You can also use giraph for a superfast PageRank implementation. Giraph even runs on standard hadoop clusters. Pagerank is usually computed by power iteration, which is much simpler than lanczos or ssvd and only gives the eigenvector associated with the largest eigenvalue. Am 18.02.2014 09:33 schrieb "Peng Cheng" : > Really? I guess PageRank in mahout was removed due to inherited network > bottleneck of mapreduce. But I didn't know MLlib has the implementation. Is > mllib implementation based on Lanczos or SSVD? Just curious... > > On 17/02/2014 11:11 PM, Dmitriy Lyubimov wrote: > >> I bet page rank in mllib in spark finds stationary distribution much >> faster. >> On Feb 17, 2014 1:33 PM, "peng" wrote: >> >> Agreed, and this is the case where Lanczos algorithm is obsolete. >>> My point is: if SSVD is unable to find the eigenvector of asymmetric >>> matrix (this is a common formulation of PageRank, and some random walks, >>> and many other things), then we still have to rely on large-scale Lanczos >>> algorithm. >>> >>> On Mon 17 Feb 2014 04:25:16 PM EST, Ted Dunning wrote: >>> >>> For the symmetric case, SVD is eigen decomposition. On Mon, Feb 17, 2014 at 1:12 PM, peng wrote: If SSVD is not designed for such eigenvector problem. Then I would vote > for retaining the Lanczos algorithm. > However, I would like to see the opposite case, I have tested both > algorithms on symmetric case and SSVD is much faster and more accurate > than > its competitor. > > Yours Peng > > On Wed 12 Feb 2014 03:25:47 PM EST, peng wrote: > > In PageRank I'm afraid I have no other option than eigenvector > >> \lambda, but not singular vector u & v:) The PageRank in Mahout was >> removed with other graph-based algorithm. >> >> On Tue 11 Feb 2014 06:34:17 PM EST, Ted Dunning wrote: >> >> SSVD is very probably better than Lanczos for any large >> decomposition. >> >>> That said, it does SVD, not eigen decomposition which means that >>> the >>> question of symmetrical matrices or positive definiteness doesn't >>> much >>> matter. >>> >>> Do you really need eigen-decomposition? >>> >>> >>> >>> On Tue, Feb 11, 2014 at 2:55 PM, peng wrote: >>> >>>Just asking for possible replacement of our Lanczos-based PageRank >>> >>> implementation. - Peng >
Re: Does SSVD supports eigendecomposition of non-symmetric & non-positive-semidefinitive matrix better than Lanczos?
Really? I guess PageRank in mahout was removed due to inherited network bottleneck of mapreduce. But I didn't know MLlib has the implementation. Is mllib implementation based on Lanczos or SSVD? Just curious... On 17/02/2014 11:11 PM, Dmitriy Lyubimov wrote: I bet page rank in mllib in spark finds stationary distribution much faster. On Feb 17, 2014 1:33 PM, "peng" wrote: Agreed, and this is the case where Lanczos algorithm is obsolete. My point is: if SSVD is unable to find the eigenvector of asymmetric matrix (this is a common formulation of PageRank, and some random walks, and many other things), then we still have to rely on large-scale Lanczos algorithm. On Mon 17 Feb 2014 04:25:16 PM EST, Ted Dunning wrote: For the symmetric case, SVD is eigen decomposition. On Mon, Feb 17, 2014 at 1:12 PM, peng wrote: If SSVD is not designed for such eigenvector problem. Then I would vote for retaining the Lanczos algorithm. However, I would like to see the opposite case, I have tested both algorithms on symmetric case and SSVD is much faster and more accurate than its competitor. Yours Peng On Wed 12 Feb 2014 03:25:47 PM EST, peng wrote: In PageRank I'm afraid I have no other option than eigenvector \lambda, but not singular vector u & v:) The PageRank in Mahout was removed with other graph-based algorithm. On Tue 11 Feb 2014 06:34:17 PM EST, Ted Dunning wrote: SSVD is very probably better than Lanczos for any large decomposition. That said, it does SVD, not eigen decomposition which means that the question of symmetrical matrices or positive definiteness doesn't much matter. Do you really need eigen-decomposition? On Tue, Feb 11, 2014 at 2:55 PM, peng wrote: Just asking for possible replacement of our Lanczos-based PageRank implementation. - Peng
Re: Does SSVD supports eigendecomposition of non-symmetric & non-positive-semidefinitive matrix better than Lanczos?
I bet page rank in mllib in spark finds stationary distribution much faster. On Feb 17, 2014 1:33 PM, "peng" wrote: > Agreed, and this is the case where Lanczos algorithm is obsolete. > My point is: if SSVD is unable to find the eigenvector of asymmetric > matrix (this is a common formulation of PageRank, and some random walks, > and many other things), then we still have to rely on large-scale Lanczos > algorithm. > > On Mon 17 Feb 2014 04:25:16 PM EST, Ted Dunning wrote: > >> For the symmetric case, SVD is eigen decomposition. >> >> >> >> >> On Mon, Feb 17, 2014 at 1:12 PM, peng wrote: >> >> If SSVD is not designed for such eigenvector problem. Then I would vote >>> for retaining the Lanczos algorithm. >>> However, I would like to see the opposite case, I have tested both >>> algorithms on symmetric case and SSVD is much faster and more accurate >>> than >>> its competitor. >>> >>> Yours Peng >>> >>> On Wed 12 Feb 2014 03:25:47 PM EST, peng wrote: >>> >>> In PageRank I'm afraid I have no other option than eigenvector \lambda, but not singular vector u & v:) The PageRank in Mahout was removed with other graph-based algorithm. On Tue 11 Feb 2014 06:34:17 PM EST, Ted Dunning wrote: SSVD is very probably better than Lanczos for any large decomposition. >That said, it does SVD, not eigen decomposition which means that the > question of symmetrical matrices or positive definiteness doesn't much > matter. > > Do you really need eigen-decomposition? > > > > On Tue, Feb 11, 2014 at 2:55 PM, peng wrote: > > Just asking for possible replacement of our Lanczos-based PageRank > >> implementation. - Peng >> >> >> > >>
Re: Does SSVD supports eigendecomposition of non-symmetric & non-positive-semidefinitive matrix better than Lanczos?
Agreed, and this is the case where Lanczos algorithm is obsolete. My point is: if SSVD is unable to find the eigenvector of asymmetric matrix (this is a common formulation of PageRank, and some random walks, and many other things), then we still have to rely on large-scale Lanczos algorithm. On Mon 17 Feb 2014 04:25:16 PM EST, Ted Dunning wrote: For the symmetric case, SVD is eigen decomposition. On Mon, Feb 17, 2014 at 1:12 PM, peng wrote: If SSVD is not designed for such eigenvector problem. Then I would vote for retaining the Lanczos algorithm. However, I would like to see the opposite case, I have tested both algorithms on symmetric case and SSVD is much faster and more accurate than its competitor. Yours Peng On Wed 12 Feb 2014 03:25:47 PM EST, peng wrote: In PageRank I'm afraid I have no other option than eigenvector \lambda, but not singular vector u & v:) The PageRank in Mahout was removed with other graph-based algorithm. On Tue 11 Feb 2014 06:34:17 PM EST, Ted Dunning wrote: SSVD is very probably better than Lanczos for any large decomposition. That said, it does SVD, not eigen decomposition which means that the question of symmetrical matrices or positive definiteness doesn't much matter. Do you really need eigen-decomposition? On Tue, Feb 11, 2014 at 2:55 PM, peng wrote: Just asking for possible replacement of our Lanczos-based PageRank implementation. - Peng
Re: Does SSVD supports eigendecomposition of non-symmetric & non-positive-semidefinitive matrix better than Lanczos?
For the symmetric case, SVD is eigen decomposition. On Mon, Feb 17, 2014 at 1:12 PM, peng wrote: > If SSVD is not designed for such eigenvector problem. Then I would vote > for retaining the Lanczos algorithm. > However, I would like to see the opposite case, I have tested both > algorithms on symmetric case and SSVD is much faster and more accurate than > its competitor. > > Yours Peng > > On Wed 12 Feb 2014 03:25:47 PM EST, peng wrote: > >> In PageRank I'm afraid I have no other option than eigenvector >> \lambda, but not singular vector u & v:) The PageRank in Mahout was >> removed with other graph-based algorithm. >> >> On Tue 11 Feb 2014 06:34:17 PM EST, Ted Dunning wrote: >> >>> SSVD is very probably better than Lanczos for any large decomposition. >>> That said, it does SVD, not eigen decomposition which means that the >>> question of symmetrical matrices or positive definiteness doesn't much >>> matter. >>> >>> Do you really need eigen-decomposition? >>> >>> >>> >>> On Tue, Feb 11, 2014 at 2:55 PM, peng wrote: >>> >>> Just asking for possible replacement of our Lanczos-based PageRank implementation. - Peng >>>
Re: Does SSVD supports eigendecomposition of non-symmetric & non-positive-semidefinitive matrix better than Lanczos?
If SSVD is not designed for such eigenvector problem. Then I would vote for retaining the Lanczos algorithm. However, I would like to see the opposite case, I have tested both algorithms on symmetric case and SSVD is much faster and more accurate than its competitor. Yours Peng On Wed 12 Feb 2014 03:25:47 PM EST, peng wrote: In PageRank I'm afraid I have no other option than eigenvector \lambda, but not singular vector u & v:) The PageRank in Mahout was removed with other graph-based algorithm. On Tue 11 Feb 2014 06:34:17 PM EST, Ted Dunning wrote: SSVD is very probably better than Lanczos for any large decomposition. That said, it does SVD, not eigen decomposition which means that the question of symmetrical matrices or positive definiteness doesn't much matter. Do you really need eigen-decomposition? On Tue, Feb 11, 2014 at 2:55 PM, peng wrote: Just asking for possible replacement of our Lanczos-based PageRank implementation. - Peng
Re: Does SSVD supports eigendecomposition of non-symmetric & non-positive-semidefinitive matrix better than Lanczos?
In PageRank I'm afraid I have no other option than eigenvector \lambda, but not singular vector u & v:) The PageRank in Mahout was removed with other graph-based algorithm. On Tue 11 Feb 2014 06:34:17 PM EST, Ted Dunning wrote: SSVD is very probably better than Lanczos for any large decomposition. That said, it does SVD, not eigen decomposition which means that the question of symmetrical matrices or positive definiteness doesn't much matter. Do you really need eigen-decomposition? On Tue, Feb 11, 2014 at 2:55 PM, peng wrote: Just asking for possible replacement of our Lanczos-based PageRank implementation. - Peng
Re: Does SSVD supports eigendecomposition of non-symmetric & non-positive-semidefinitive matrix better than Lanczos?
SSVD is very probably better than Lanczos for any large decomposition. That said, it does SVD, not eigen decomposition which means that the question of symmetrical matrices or positive definiteness doesn't much matter. Do you really need eigen-decomposition? On Tue, Feb 11, 2014 at 2:55 PM, peng wrote: > Just asking for possible replacement of our Lanczos-based PageRank > implementation. - Peng >
Does SSVD supports eigendecomposition of non-symmetric & non-positive-semidefinitive matrix better than Lanczos?
Just asking for possible replacement of our Lanczos-based PageRank implementation. - Peng
Re: EigenDecomposition
Weekend is coming.
On Thu, Jul 11, 2013 at 11:07 AM, Grant Ingersoll wrote:
> FWIW, the only way we are getting out of code freeze is if we actually get
> some feedback on the RC. It passes my tests, but I haven't heard from
> others much.
>
> -Grant
>
> On Jul 10, 2013, at 5:13 PM, Dmitriy Lyubimov wrote:
>
> > meant, after code freeze is over.
> >
> >
> > On Wed, Jul 10, 2013 at 2:13 PM, Dmitriy Lyubimov
> wrote:
> >
> >> fixed as part of MAHOUT-1281 patch now. I will push after code freeze.
> >>
> >>
> >> On Wed, Jul 10, 2013 at 2:06 PM, Ted Dunning >wrote:
> >>
> >>> Please file. Looks completely innocuous and it is good to be standard.
> >>>
> >>>
> >>> On Wed, Jul 10, 2013 at 12:59 PM, Dmitriy Lyubimov >>>> wrote:
> >>>
> >>>> Looks like Lanczos is having the same problem and need to undo some
> >>>> workarounds :
> >>>>
> >>>>EigenDecomposition decomp = new EigenDecomposition(triDiag);
> >>>>
> >>>>Matrix eigenVects = decomp.getV();
> >>>>Vector eigenVals = decomp.getRealEigenvalues();
> >>>>endTime(TimingSection.TRIDIAG_DECOMP);
> >>>>startTime(TimingSection.FINAL_EIGEN_CREATE);
> >>>>for (int row = 0; row < i; row++) {
> >>>> Vector realEigen = null;
> >>>> // the eigenvectors live as columns of V, in reverse order.
> Weird
> >>>> but true.
> >>>> Vector ejCol = eigenVects.viewColumn(i - row - 1);
> >>>> int size = Math.min(ejCol.size(), state.getBasisSize());
> >>>>
> >>>>
> >>>>
> >>>> On Wed, Jul 10, 2013 at 12:53 PM, Dmitriy Lyubimov >>>>> wrote:
> >>>>
> >>>>> changing line 329 of EigenDecomposition.java from
> >>>>>
> >>>>>if (d.getQuick(j) < p) {
> >>>>>
> >>>>> to
> >>>>>if (d.getQuick(j) > p) {
> >>>>>
> >>>>>
> >>>>> makes my MAHOUT-1281 patch work.
> >>>>>
> >>>>> should i keep the change? (question for Ted, i guess)
> >>>>>
> >>>>> thanks.
> >>>>> -D
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Wed, Jul 10, 2013 at 11:59 AM, Dmitriy Lyubimov <
> dlie...@gmail.com
> >>>>> wrote:
> >>>>>
> >>>>>> It looks like values out of our ported EigenDecomposition are coming
> >>> out
> >>>>>> sorted in inverse order.
> >>>>>>
> >>>>>> Shouldn't it be the other way around?
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >>
>
>
> Grant Ingersoll | @gsingers
> http://www.lucidworks.com
>
>
>
>
>
>
Re: EigenDecomposition
FWIW, the only way we are getting out of code freeze is if we actually get some
feedback on the RC. It passes my tests, but I haven't heard from others much.
-Grant
On Jul 10, 2013, at 5:13 PM, Dmitriy Lyubimov wrote:
> meant, after code freeze is over.
>
>
> On Wed, Jul 10, 2013 at 2:13 PM, Dmitriy Lyubimov wrote:
>
>> fixed as part of MAHOUT-1281 patch now. I will push after code freeze.
>>
>>
>> On Wed, Jul 10, 2013 at 2:06 PM, Ted Dunning wrote:
>>
>>> Please file. Looks completely innocuous and it is good to be standard.
>>>
>>>
>>> On Wed, Jul 10, 2013 at 12:59 PM, Dmitriy Lyubimov >>> wrote:
>>>
>>>> Looks like Lanczos is having the same problem and need to undo some
>>>> workarounds :
>>>>
>>>>EigenDecomposition decomp = new EigenDecomposition(triDiag);
>>>>
>>>>Matrix eigenVects = decomp.getV();
>>>>Vector eigenVals = decomp.getRealEigenvalues();
>>>>endTime(TimingSection.TRIDIAG_DECOMP);
>>>>startTime(TimingSection.FINAL_EIGEN_CREATE);
>>>>for (int row = 0; row < i; row++) {
>>>> Vector realEigen = null;
>>>> // the eigenvectors live as columns of V, in reverse order. Weird
>>>> but true.
>>>> Vector ejCol = eigenVects.viewColumn(i - row - 1);
>>>> int size = Math.min(ejCol.size(), state.getBasisSize());
>>>>
>>>>
>>>>
>>>> On Wed, Jul 10, 2013 at 12:53 PM, Dmitriy Lyubimov >>>> wrote:
>>>>
>>>>> changing line 329 of EigenDecomposition.java from
>>>>>
>>>>> if (d.getQuick(j) < p) {
>>>>>
>>>>> to
>>>>>if (d.getQuick(j) > p) {
>>>>>
>>>>>
>>>>> makes my MAHOUT-1281 patch work.
>>>>>
>>>>> should i keep the change? (question for Ted, i guess)
>>>>>
>>>>> thanks.
>>>>> -D
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Jul 10, 2013 at 11:59 AM, Dmitriy Lyubimov >>>> wrote:
>>>>>
>>>>>> It looks like values out of our ported EigenDecomposition are coming
>>> out
>>>>>> sorted in inverse order.
>>>>>>
>>>>>> Shouldn't it be the other way around?
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
Grant Ingersoll | @gsingers
http://www.lucidworks.com
Re: EigenDecomposition
meant, after code freeze is over.
On Wed, Jul 10, 2013 at 2:13 PM, Dmitriy Lyubimov wrote:
> fixed as part of MAHOUT-1281 patch now. I will push after code freeze.
>
>
> On Wed, Jul 10, 2013 at 2:06 PM, Ted Dunning wrote:
>
>> Please file. Looks completely innocuous and it is good to be standard.
>>
>>
>> On Wed, Jul 10, 2013 at 12:59 PM, Dmitriy Lyubimov > >wrote:
>>
>> > Looks like Lanczos is having the same problem and need to undo some
>> > workarounds :
>> >
>> > EigenDecomposition decomp = new EigenDecomposition(triDiag);
>> >
>> > Matrix eigenVects = decomp.getV();
>> > Vector eigenVals = decomp.getRealEigenvalues();
>> > endTime(TimingSection.TRIDIAG_DECOMP);
>> > startTime(TimingSection.FINAL_EIGEN_CREATE);
>> > for (int row = 0; row < i; row++) {
>> > Vector realEigen = null;
>> > // the eigenvectors live as columns of V, in reverse order. Weird
>> > but true.
>> > Vector ejCol = eigenVects.viewColumn(i - row - 1);
>> > int size = Math.min(ejCol.size(), state.getBasisSize());
>> >
>> >
>> >
>> > On Wed, Jul 10, 2013 at 12:53 PM, Dmitriy Lyubimov > > >wrote:
>> >
>> > > changing line 329 of EigenDecomposition.java from
>> > >
>> > > if (d.getQuick(j) < p) {
>> > >
>> > > to
>> > > if (d.getQuick(j) > p) {
>> > >
>> > >
>> > > makes my MAHOUT-1281 patch work.
>> > >
>> > > should i keep the change? (question for Ted, i guess)
>> > >
>> > > thanks.
>> > > -D
>> > >
>> > >
>> > >
>> > >
>> > > On Wed, Jul 10, 2013 at 11:59 AM, Dmitriy Lyubimov > > >wrote:
>> > >
>> > >> It looks like values out of our ported EigenDecomposition are coming
>> out
>> > >> sorted in inverse order.
>> > >>
>> > >> Shouldn't it be the other way around?
>> > >>
>> > >
>> > >
>> >
>>
>
>
Re: EigenDecomposition
fixed as part of MAHOUT-1281 patch now. I will push after code freeze.
On Wed, Jul 10, 2013 at 2:06 PM, Ted Dunning wrote:
> Please file. Looks completely innocuous and it is good to be standard.
>
>
> On Wed, Jul 10, 2013 at 12:59 PM, Dmitriy Lyubimov >wrote:
>
> > Looks like Lanczos is having the same problem and need to undo some
> > workarounds :
> >
> > EigenDecomposition decomp = new EigenDecomposition(triDiag);
> >
> > Matrix eigenVects = decomp.getV();
> > Vector eigenVals = decomp.getRealEigenvalues();
> > endTime(TimingSection.TRIDIAG_DECOMP);
> > startTime(TimingSection.FINAL_EIGEN_CREATE);
> > for (int row = 0; row < i; row++) {
> > Vector realEigen = null;
> > // the eigenvectors live as columns of V, in reverse order. Weird
> > but true.
> > Vector ejCol = eigenVects.viewColumn(i - row - 1);
> > int size = Math.min(ejCol.size(), state.getBasisSize());
> >
> >
> >
> > On Wed, Jul 10, 2013 at 12:53 PM, Dmitriy Lyubimov > >wrote:
> >
> > > changing line 329 of EigenDecomposition.java from
> > >
> > > if (d.getQuick(j) < p) {
> > >
> > > to
> > > if (d.getQuick(j) > p) {
> > >
> > >
> > > makes my MAHOUT-1281 patch work.
> > >
> > > should i keep the change? (question for Ted, i guess)
> > >
> > > thanks.
> > > -D
> > >
> > >
> > >
> > >
> > > On Wed, Jul 10, 2013 at 11:59 AM, Dmitriy Lyubimov > >wrote:
> > >
> > >> It looks like values out of our ported EigenDecomposition are coming
> out
> > >> sorted in inverse order.
> > >>
> > >> Shouldn't it be the other way around?
> > >>
> > >
> > >
> >
>
Re: EigenDecomposition
Please file. Looks completely innocuous and it is good to be standard.
On Wed, Jul 10, 2013 at 12:59 PM, Dmitriy Lyubimov wrote:
> Looks like Lanczos is having the same problem and need to undo some
> workarounds :
>
> EigenDecomposition decomp = new EigenDecomposition(triDiag);
>
> Matrix eigenVects = decomp.getV();
> Vector eigenVals = decomp.getRealEigenvalues();
> endTime(TimingSection.TRIDIAG_DECOMP);
> startTime(TimingSection.FINAL_EIGEN_CREATE);
> for (int row = 0; row < i; row++) {
> Vector realEigen = null;
> // the eigenvectors live as columns of V, in reverse order. Weird
> but true.
> Vector ejCol = eigenVects.viewColumn(i - row - 1);
> int size = Math.min(ejCol.size(), state.getBasisSize());
>
>
>
> On Wed, Jul 10, 2013 at 12:53 PM, Dmitriy Lyubimov >wrote:
>
> > changing line 329 of EigenDecomposition.java from
> >
> > if (d.getQuick(j) < p) {
> >
> > to
> > if (d.getQuick(j) > p) {
> >
> >
> > makes my MAHOUT-1281 patch work.
> >
> > should i keep the change? (question for Ted, i guess)
> >
> > thanks.
> > -D
> >
> >
> >
> >
> > On Wed, Jul 10, 2013 at 11:59 AM, Dmitriy Lyubimov >wrote:
> >
> >> It looks like values out of our ported EigenDecomposition are coming out
> >> sorted in inverse order.
> >>
> >> Shouldn't it be the other way around?
> >>
> >
> >
>
Re: EigenDecomposition
Looks like Lanczos is having the same problem and need to undo some
workarounds :
EigenDecomposition decomp = new EigenDecomposition(triDiag);
Matrix eigenVects = decomp.getV();
Vector eigenVals = decomp.getRealEigenvalues();
endTime(TimingSection.TRIDIAG_DECOMP);
startTime(TimingSection.FINAL_EIGEN_CREATE);
for (int row = 0; row < i; row++) {
Vector realEigen = null;
// the eigenvectors live as columns of V, in reverse order. Weird
but true.
Vector ejCol = eigenVects.viewColumn(i - row - 1);
int size = Math.min(ejCol.size(), state.getBasisSize());
On Wed, Jul 10, 2013 at 12:53 PM, Dmitriy Lyubimov wrote:
> changing line 329 of EigenDecomposition.java from
>
> if (d.getQuick(j) < p) {
>
> to
> if (d.getQuick(j) > p) {
>
>
> makes my MAHOUT-1281 patch work.
>
> should i keep the change? (question for Ted, i guess)
>
> thanks.
> -D
>
>
>
>
> On Wed, Jul 10, 2013 at 11:59 AM, Dmitriy Lyubimov wrote:
>
>> It looks like values out of our ported EigenDecomposition are coming out
>> sorted in inverse order.
>>
>> Shouldn't it be the other way around?
>>
>
>
Re: EigenDecomposition
changing line 329 of EigenDecomposition.java from
if (d.getQuick(j) < p) {
to
if (d.getQuick(j) > p) {
makes my MAHOUT-1281 patch work.
should i keep the change? (question for Ted, i guess)
thanks.
-D
On Wed, Jul 10, 2013 at 11:59 AM, Dmitriy Lyubimov wrote:
> It looks like values out of our ported EigenDecomposition are coming out
> sorted in inverse order.
>
> Shouldn't it be the other way around?
>
EigenDecomposition
It looks like values out of our ported EigenDecomposition are coming out sorted in inverse order. Shouldn't it be the other way around?
