Re: svds.m change to avoid test failure

[Michael D. Godfrey]

On 3/1/10 11:03 AM, John W. Eaton wrote:
> On 28-Feb-2010, Michael D. Godfrey wrote:
>
> | Attached is the one line change.
> |
> | Michael
> |
> |
> | ----------------------------------------------------------------------
> | # HG changeset patch
> | # User Michael Godfrey<address@hidden>
> | # Date 1267387707 28800
> | # Node ID a6c5165a0522b1bc14aedc3e77276dcc15ef1928
> | # Parent  1f11fabfa34957118b2a7c3a118f2e9e1c8cbd51
> | avoid test failure in svds test
> |
> | diff -r 1f11fabfa349 -r a6c5165a0522 scripts/sparse/svds.m
> | --- a/scripts/sparse/svds.m   Sun Feb 28 12:32:16 2010 -0500
> | +++ b/scripts/sparse/svds.m   Sun Feb 28 12:08:27 2010 -0800
> | @@ -219,7 +219,7 @@
> |  %! assert(flag,!1);
> |  %! assert(s(end:-1:end-k+1), s2, 1e-10);
> |  %!testif HAVE_ARPACK
> | -%! [u2,s2,v2,flag] = svds(a,k,0);
> | +%! [u2,s2,v2,flag] = svds(a,k,0.05);
> |  %! s2 = diag(s2);
> |  %! assert(flag,!1);
> |  %! assert(s(k:-1:1), s2, 1e-10);
>
> This may avoid the test failure, but I'm not sure it is best to do
> that.
>
> I know it is iterative, but it seems bad to me that the algorithm used
> for svds can return different results on successive runs.  That kind
> of behavior does not inspire confidence.  I'd rather not hide behavior
> like that by changing the test.
>
> jwe
>    
I do not think that this change exactly hides the problem that has not 
been solved.  As
I read the test it is to determine if svds returns the k correct 
eigenvalues.  So, using
a call which ensures that the k intended eigenvalues are returned seems 
appropriate.
When we figure out where the inconsistent behavior comes from, we should 
figure
out a test to catch it in case it comes back.

Right now all I can think of about the inconsistency problem is that the 
context
when the tests are run is somehow different from running the same test 
in the
normal Octave environment (at least my environment).

Michael