Re: test failures for svds.m

[Rik]

> With my last build, I encountered a test error for svds.m. My tip is
> 
> changeset:   10665:0f310fce905d
> tag:         tip
> user:        Jaroslav Hajek <address@hidden>
> date:        Thu May 27 08:54:44 2010 +0200
> summary:     implement octave_base_matrix::matrix_ref const
> 
> The test error is …
> 
>>>>>> processing 
>>>>>> /Users/bpabbott/Development/mercurial/local_clone/scripts/sparse/svds.m
>   ***** testif HAVE_ARPACK
>  [u2,s2,v2,flag] = svds(a,k,0,opts);
>  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
> 
> If I make the change below, the test passes.
> 
> %! [u2,s2,v2,flag] = svds(a,k,0);#,opts);
> 

Interesting, as I went to a lot of trouble to fix this.
Previously, svds was failing ~30% of the time with no
discernible pattern.

The issue seems to be that svds calls eigs which in turn
calls routines from ARPACK.  The ARPACK routines are
iterative and depend upon an initial starting point.  In
the Octave test code we are careful to initialize all
the random number generators so that results are reproducible.
However, in this case we were letting ARPACK choose the
initial starting point using its own random number generator.

My solution was to pass in a starting point to ARPACK that
the Octave test code generates and therefore can make
reproducible.  This was my changeset 10660:4cdc43c095c5.

I've run the svds tests over 3,000 times now and I can't
get them to fail.

I can think of a few possibilities, but none of them are
great.  One, perhaps the random number generators in Octave
don't produce the same results across different platforms, gcc
compiler versions, etc.  Two, the ARPACK routines
might not be deterministic even with the same starting point.

If you have spare cycles we can try to debug the first one.  I
can send you the vector that I am using for initialization and
see how it compares to yours.

--Rik