octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 'make check' errors for Mac OS X


From: Daniel J Sebald
Subject: Re: 'make check' errors for Mac OS X
Date: Sun, 03 Nov 2013 10:58:44 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

On 11/03/2013 05:53 AM, c. wrote:

On 3 Nov 2013, at 09:05, Dmitri A. Sergatskov<address@hidden>  wrote:

On my Fedora 19 (x86_64) it passes with reference BLAS  but fails with ATLAS
and OpenBLAS.

Dmitri.

I am using ATLAS on OSX too, is the error you get the same as for me?

svds.m
  ***** testif HAVE_ARPACK
[u2,s2,v2,flag] = svds (A,k);
s2 = diag (s2);
assert (flag, !1);
tol = 10 * eps() * norm(s2, 1);
assert (s2, s(end:-1:end-k+1), tol);

!!!!! test failed
ASSERT errors for:  assert (s2,s (end:-1:end - k + 1),tol)

  Location  |  Observed  |  Expected  |  Reason
    (6)         41.966       41.966      Abs err 6.8923e-13 exceeds tol 
6.5244e-13

c.

This certainly looks like a tolerance issue, but there is something not exactly right--at least something that warrants a bit of investigation. With the norm() scaling in the tolerance it seems a pretty loose bound, but I suppose it is the nature of the problem given the A matrix looks to be rank 7. The weak eigenvalues that should theoretically be zero will probably have a large degree of noise, and being sorted might taper off (one of the reasons I added a vector tolerance for assert as opposed to just a scalar tolerance).

A few things.

First, this norm(s2,1) is done on the sparse matrix, which represents the non-zero eigenvalue portion (i.e., those theoretically with rank, or singular values) of the matrix. There is this whole other set of near-zero eigenvalues (93 of them?) for which that subspace is adding noise to the result. Perhaps there needs to be a term introduced into the tolerance for that.

Second, having not looked too closely at the matrix itself, from the way it is constructed I would guess it is of rank 7. Maybe it isn't of rank 7, but if that were the case, my guess would be it is the last singular value where the most discrepancy is, not the second last.

Lastly, if there is some inaccuracy here, we aren't sure if it is the sparse SVD routine or the non-sparse SVD routine which is worse. It might be nice to have a test that compares against some theoretical result.

In any case, David, could you investigate this issue a bit to see if you are comfortable with the result?

Dan


reply via email to

[Prev in Thread] Current Thread [Next in Thread]