Re: [eigen] SVD Bug
• To: eigen@xxxxxxxxxxxxxxxxxxx
• Subject: Re: [eigen] SVD Bug
• From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
• Date: Fri, 24 Sep 2010 10:55:58 -0400
• 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:content-transfer-encoding; b=o1p9VUbcX1dnfxY3hR5SRAKmz3HAWcrUckg/XWtmxPRtRxtwx70CXdnF1r8Ds5yWNB gIYKqpbQMskj6Qcp9vO9x4VGVe9RgyvFUf92pyBvpko60DWerPG6f1jT/xpJJLzMh7vn hukNz+lSm8rp36UxRvHWHaZczL2qu+Nbr+SPw=

```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>:
>>> 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
> 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/