octave-maintainers
[Top][All Lists]
Advanced

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

Re: new snapshot?


From: Michael D. Godfrey
Subject: Re: new snapshot?
Date: Fri, 26 Feb 2010 09:55:17 -0800
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2

On 2/26/10 3:01 AM, John W. Eaton wrote:
On 26-Feb-2010, Michael D. Godfrey wrote:

| I built the current system on Fedora 12 x86_64 with default
| settings and got only one test failure:
|
|>>>>>  processing /data/d/src/octave/hg/octave/scripts/sparse/svds.m
|    ***** testif HAVE_ARPACK
|   [u2,s2,v2,flag] = svds(a,k,0);
|   s2 = diag(s2);
|   assert(flag,!1);
|   assert(s(k:-1:1), s2, 1e-10);
| !!!!! test failed
| assert (s (k:-1:1),s2,1e-10) expected
|     38.060
|     38.060
|     38.034
|     38.034
|     38.015
|     38.015
|     38.004
| but got
|     38.060
|     38.034
|     38.034
|     38.015
|     38.015
|     38.004
|     38.004
| maximum absolute error 0.0263523 exceeds tolerance 1e-10
| The version of arpack is: arpack-2.1-12.fc12.x86_64
| Looks like an indexing error.

It could be.  Here's what I know.  The test calls svds.  The call to
svds in eigs is sometimes returning

   s =

      0.95151
      0.95085
      0.95085
      0.95038
      0.95038
      0.95009
      0.95009
     -0.95009
     -0.95009
     -0.95038
     -0.95038
     -0.95085
     -0.95085
     -0.95151

(apparently this is the result we expect) but sometimes it is
returning

   s =

      0.95085
      0.95085
      0.95038
      0.95038
      0.95009
      0.95009
     -0.95009
     -0.95009
     -0.95038
     -0.95038
     -0.95085
     -0.95085
     -0.95151
     -0.95151

and other times it is returning

   s =

      0.95151
      0.95151
      0.95085
      0.95085
      0.95038
      0.95038
      0.95009
      0.95009
     -0.95009
     -0.95009
     -0.95038
     -0.95038
     -0.95085
     -0.95085

A slightly simpler test script that should demonstrate this problem
directly without needing svds is

   z = sparse (100, 100);
   d = repmat (1/40, [1, 98]);
   b = sparse (eye (100) + diag (d, 2) + diag (d, -2));
   m = [z, b; b', z];
   b_sigma = sparse (1, 1);
   b_opts.tol = sparse (1, 1, 1e-10/40/sqrt(2));
   b_opts.disp = 0;
   b_opts.maxit = 300;
   [V, s, flag] = eigs (m, 14, b_sigma, b_opts);
   s = diag (s)

That's as far as I've been able to get so far.  I don't know whether
the problem is in the way we are using arpack to compute he
eigenvalues, or if it is in arpack itself.

jwe
This is strange.  Here is all I can add:

If I extract the svds test and run it separately it always (so far) succeeds.
The error when run in make check is that the s result in:
assert(s(k:-1:1), s2, 1e-10);
is incorrect (shifted).  s2 appears to always be correct.  Therefore, the
sequence:
a = sparse([3:n,1:n,1:(n-2)],[1:(n-2),1:n,3:n],[ones(1,n-2),0.4*n*ones(1,n),ones(1,n-2)]);
[u,s,v] = svd(full(a));
must be where the error happens.

Hard to see how this can be. :-(

Michael



reply via email to

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