Re: [eigen] SVD Bug

[ Thread Index | Date Index | More Archives ]

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.


> 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+