Re: [eigen] Re: Complete orthogonal decomposition rank computation corner case

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


Hi,

In my opinion this is hiding a more fundamental issue, and this patch would just hide it for eternity... We should rather try to understand why the rank does change, but since the issue does not occur with 3.3, maybe the problem comes from 3.2.6's ColPivHouseholderQR or from a shortcoming in your backport. What if you upgrade to 3.2's head? 

gael

On Fri, Jun 24, 2016 at 12:43 AM, Rasmus Larsen <rmlarsen@xxxxxxxxxx> wrote:
Hi Simon,

Thanks for the patch. I've just gotten back from vacation, but it seems reasonable to me. I'll look more carefully shortly.

Rasmus

On Wed, Jun 15, 2016 at 11:41 PM, Simon Rutishauser <simon.rutishauser@xxxxxxxxx> wrote:
Hi list and Rasmus,

I have been playing around with the complete orthogonal decomposition that was recently added to Eigen,
and I think I have ran into a corner case:

I have a matrix of size 70 where the rank() in the CompleteOrthogonalDecomposition::compute() method is 69,
it thus performs the additional Householder reflections. After those reflections, the rank() method returns 70.

Next I run the pseudoInverse() method, which in consequence skips the applyZAdjointOnTheLeftInPlace() step.
The resulting matrix is completely wrong.

The solution, as far as I can see it, would be to the rank() obtained directly after the QR decomposition
and then stick with it.

What do you think? I have attached a proposed patch.

Simon

P.S. I'd love to provide an example matrix that triggers this behaviour, but unfortunately I only observe
this corner-case on Eigen 3.2.6 with a backported CompleteOrthogonalDecomposition. So the issues I am
observing may also have other origins.




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