Re: [eigen] inconsistency in fast eigen decomposition |

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] inconsistency in fast eigen decomposition*From*: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>*Date*: Thu, 3 Feb 2011 09:00:00 -0500*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=ULH6Vnf/K/H371hU1O70H3thUxgS8Iq3PyVcNhM4D6w=; b=s0i1ihxZ2izuYaeiiJdnyhixuyZdT4yWoyY7pZpOJbyajdhGjxC4qitrzZAGzM7QOb t4pT7fOUgxeG84EDIwTR/Z8jpCuJOLWwTQUMoolRqBrIWpyilrxF98N5xbLRcxFNgfm9 HUispDrsw0a/yeFniPa4LpgK7nrTj4IEdqhk8=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=VnlWTUHv0w2rB49IPXVFWI7yYEu8fYyhABf6hdSkW1T5D4XG62Ks/1m9JkwjF6uD3D fVTU2VBNQ6DktM16XN8cbW7jj8CH8NGkaPMUJejlMkjJsiSnrq44Gj9pcB4JOWr9pQ8+ j8cNFOBZUXcbWi3oNPrkLIi9j4Rw24y691sQ4=

Oh! I thought that we were talking about a bug in Eigen here. Sorry. Benoit 2011/2/3 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>: > he is not using something which is officially in eigen, but a function > which is in bench/eig33.cpp that I added for benchmarking purpose and > possible inclusion in Eigen in the future. The main question is how to > integrate it (option of SelfAdjointEigenSolver, a new class, both...) > That can be discussed for 3.1 since there already is a template > Options parameter in SelfAdjointEigenSolver. > > gael > > On Thu, Feb 3, 2011 at 2:24 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote: >> Could a unit test be added? Maybe just take his matrix, decompose, >> reconstruct original matrix, compare. My understanding is that before >> your fix, eigen would have given a completely wrong reconstructed >> matrix, so just a fuzzy compare at default test precision would be >> good enough. >> >> Benoit >> >> 2011/2/3 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>: >>> yes but was is strange in Radu's example is that the direct method >>> find a negative eigenvalue while they should all be positive (or equal >>> to zero). I guess that's because of the multiple trigonometric >>> functions. Anyway, now I start to compute the eigenvectors from the >>> biggest eigenvalue and compute the last eigenvectors from the first >>> two while taking care of some degenerated cases. >>> >>> gael >>> >>> On Thu, Feb 3, 2011 at 1:52 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote: >>>> Yeah, it's hard to be accurate when there are degenerate eigenvalues. >>>> Radu's example had well separated eigenvalues. >>> >>> >>> >> >> >> > > >

**References**:**[eigen] inconsistency in fast eigen decomposition***From:*Radu Bogdan Rusu

**Re: [eigen] inconsistency in fast eigen decomposition***From:*Gael Guennebaud

**Re: [eigen] inconsistency in fast eigen decomposition***From:*Benoit Jacob

**Re: [eigen] inconsistency in fast eigen decomposition***From:*Gael Guennebaud

**Re: [eigen] inconsistency in fast eigen decomposition***From:*Benoit Jacob

**Re: [eigen] inconsistency in fast eigen decomposition***From:*Gael Guennebaud

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] inconsistency in fast eigen decomposition** - Next by Date:
**Re: [eigen] Idea: BLAS backend** - Previous by thread:
**Re: [eigen] inconsistency in fast eigen decomposition** - Next by thread:
**Re: [eigen] inconsistency in fast eigen decomposition**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |