[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: QR failing 1 test without qrupdate library
From: |
Jaroslav Hajek |
Subject: |
Re: QR failing 1 test without qrupdate library |
Date: |
Sat, 8 May 2010 20:58:34 +0200 |
On Sat, May 8, 2010 at 7:54 PM, Rik <address@hidden> wrote:
> While trying to debug another problem, I had occasion to compile octave
> without most of it's helper libraries. When running 'make check' the qr
> test suite failed on this test:
>
> AA = single([0.091364 0.613038 0.027504 0.999083;
> 0.594638 0.425302 0.562834 0.603537;
> 0.383594 0.291238 0.742073 0.085574;
> 0.265712 0.268003 0.783553 0.238409;
> 0.669966 0.743851 0.457255 0.445057 ]);
>
> [Q,R] = qr(AA);
> [Q,R] = qrdelete(Q,R,3,'row');
> assert(norm(vec(Q'*Q - eye(4,'single')),Inf) < 1e1*eps('single'))
>
> The norm as calculated by Octave is 1.4305e-06, whereas the tolerance is
> 1.1921e-06.
>
> According to Octave when running the qrdelete step
>
> warning: In this version of Octave, QR & Cholesky updating routines
> simply update the matrix and recalculate factorizations.
> To use fast algorithms, link Octave with the qrupdate library.
>
> My understanding is that the QR routines from qrupdate are not only faster
> but more accurate. When I link against them the error is always less than
> the tolerance in the assert block.
>
If qrupdate is not available, then
[Q,R] = qrdelete(Q,R,3,'row');
is performed simply by doing
TMP = Q*R;
TMP(3,:) = [];
[Q,R] = qr (TMP);
it's not clear whether this should be more or less accurate that
qrupdate's direct update using Givens rotations. But in any case, the
resulting Q matrix is from a standard QR factorization.
> My solution would be to transform this test into two tests with one
> protected by a testif HAVE_QRUPDATE which uses the lower tolerance and an
> ordinary block which uses a higher tolerance. On the other hand, I thought
> I would post in case someone believes that the tolerance should be the same
> and there is another reason why this is failing.
>
I'm OK with this solution.
--
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz