Re: test failures for svds.m

[Ben Abbott]

On May 27, 2010, at 1:49 PM, Rik wrote:

> 
>> 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


Ok. Please send me the vector with instructions on what needs to be done.

Ben