Re: [eigen] Bug in SelfAdjointEigenSolver<>, or am I missing something important?

[Jose Luis Blanco <joseluisblancoc@xxxxxxxxx>]

Ok, done here: http://eigen.tuxfamily.org/bz/show_bug.cgi?id=107

Again, thanks for the support, and for the good work!

JL

On Thu, Nov 4, 2010 at 1:22 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> 2010/11/3 Jose Luis Blanco <joseluisblancoc@xxxxxxxxx>:
>> Hello all,
>>
>> I attach a little test program. It basically takes a square symmetric
>> matrix and computes its eigen{vectors,values} with
>> SelfAdjointEigenSolver<>, then reconstruct the original matrix with
>> EVEC * diag(EVALS) * EVEC^T.
>>
>> The point is, that works for a ColMajor ordering, but not with a
>> RowMajor, so, for these two tests:
>>
>>        myTest< Eigen::Matrix<double,4,4,ColMajor> >();
>>        myTest< Eigen::Matrix<double,4,4,RowMajor> >();
>>
>> it fails in the latter.
>>
>> From what I've learned of Eigen, everything is prepared so users can
>> use or even mix ColMajor & RowMajor matrices and everything is smart
>> enough to handle it.. but in this case.
>
> Indeed, the storage order is semantically transparent as long as you
> don't directly address the array of coeffs.
>
> In your test program, you actually do address it by using the Matrix
> constructor taking a pointer, but that still shouldn't make any
> difference in your case since your matrix is symmetric.
>
> So yes you found a bug. Thanks to your great test case I'm sure it'll
> be fixed soon, the best thing you could do is file a bug and attach
> your test case.
>
> Benoit
>
>>
>> Please, let me know if I'm missing something. I managed to solve it by
>> setting the template argument of SelfAdjointEigenSolver<> to a
>> ColMajor version of the input matrix, but I guess that implies a
>> (transparent from my viewpoint) conversion, which may be an avoidable
>> delay for big matrices if there's a better way.
>>
>> Best,
>> Jose Luis
>>
>> btw: Huge congrats to you all developers for this *absolutely
>> marvelous* library!
>>
>
>