[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] SVD Bug
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Fri, 24 Sep 2010 10:55:58 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=sxxuaRF5ZS+/T/839SyxN+RAxK6ohLg7YelppCtS0N4=; b=heUNXiA6qts/cugCw5t6fFwowWBVeBkPOAMLOz2x4zphBBV4r9nv5/rJP+fPoUbtih x/w3wcuiOCly84QVGuIz/P2qrt0QWroh4SVONGIgJ9RPrd/XM85ZXiBQm4jdJsMhDHF6 6xkvgVu+1zLhV5lOMR80oTXBE5AqcbiXSopOo=
- 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>:
>>> 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.
>> 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.
>>> - Hauke