octave-maintainers
[Top][All Lists]
Advanced

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

Re: new snapshot?


From: Jaroslav Hajek
Subject: Re: new snapshot?
Date: Fri, 26 Feb 2010 19:15:31 +0100

On Fri, Feb 26, 2010 at 6:55 PM, Michael D. Godfrey
<address@hidden> wrote:
> 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
>

Are you sure? This is exactly the opposite of what I get. Sometimes
the assert fails with

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

and the latter result is correct, AFAIK.

-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz



reply via email to

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