Re: [eigen] SVD Bug

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


2010/9/24 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
> 2010/9/24 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
>> 2010/9/24 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>:
>>> I added Gram Schmidt orthogonalization and I added Helmut's proposal
>>> to use the normal equations to evaluate least squares solutions.
>>>
>>> Again, a little check would be great!
>> Excellent. Since you check with VERIFY_IS_UNITARY, you have proof that
>> your Gram-Schmidt code is correct.
>
> Ah wait! You do have one reliability issue. Here, at column i, you
> start with the i-th vector of the standard basis (0,...,0,1,0,..,0
> with the 1 at the i-th position). This will fail (or be  numerically
> instable) if this vector happens to be in the linear span of the
> previous columns (or approximately in the linear span). So you have to
> nest another loop here: at every col, try all vectors in the standard
> basis until the norm of the projection is big enough. I am pretty sure
> that big enough means that the norm be >= 1/sqrt(n) since in the 2D
> case, clearly you can get 1/sqrt(2). So check that the squared norm is
> 1/n. Might want to say 1/(2*n) to be a little tolerant, since in case
> it's exactly 1/n, some FP imprecision could play tricks.

....or since we're in SVD which favors speed over accuracy anyway,
perhaps just check that the norm is > epsilon. So you'll succeed at
the st try in almost every case. You decide.

Benoit

>
> Benoit
>
>
>
>>
>> Also, good idea, to use the normal equations. Allows the test to be
>> more general since now you're testing arbitrary RHS.
>>
>>>
>>> Unit tests svd_1 to svd_4 do all pass but svd_9 fails. It seems as if
>>> it gets stuck, no error message, no nothing. What is this test for? It
>>> seems a bit strange.
>>
>> It's broken, please remove it. It seems to be trying to check that the
>> svd constructor checks that rows>=cols. But in order to do that, it
>> would have to use VERIFY_RAISES_ASSERT. And frankly, i wouldn't put
>> that right into the CALL_SUBTEST, I would put that in a function and
>> call that from CALL_SUBTEST. But don't bother if you don't have time,
>> it's OK to remove that.
>>
>> Benoit
>>
>>>
>>> - Hauke
>>>
>>
>



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