octave-maintainers
[Top][All Lists]
Advanced

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

Re: svds test failures


From: Marco atzeri
Subject: Re: svds test failures
Date: Sun, 07 Aug 2011 15:56:02 +0200
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0

On 8/7/2011 3:16 PM, Marco atzeri wrote:
On 8/6/2011 10:06 PM, Rik wrote:

Date: Sat, 06 Aug 2011 12:18:15 +0200
From: Marco atzeri

--------------

I would say that there is something different about your compiled version
of ARPACK. The tests specifically use an initialization vector so the
ARPACK code should always start in the same location in solution space
and
find the same eigenvalues. It works on UNIX systems anyways. Are you
running an octave version> 3.4.0 when ARPACK was incorporated into
Octave's build? Might you have a leftover ARPACK library on your system
from a previous version of Octave?

Cheers,
Rik


Hi Rik,

it is a recent source

$ hg tip
changeset: 12930:7bd29d875af1
tag: tip
user: Rik <address@hidden>
date: Fri Aug 05 20:36:10 2011 -0700
summary: mode.m: Eliminate cellfun usage in assert tests

and from the build log I see no evidence that the system arpack
is used, just the octave one and very recent (28 Jul)

Marco


I just found that it is a matter of the start point,
changing from

 randn('state',42);
 rand('state',42)

to

 randn('state',43);
 rand('state',43)

and I have

> [u2,s2,v2,flag] = svds(A,k,0,opts);
> s2 = diag(s2)
s2 =

   38.060
   38.034
   38.034
   38.015
   38.015
   38.004
   38.004

without changing sigma.

It seems that the test is very sensible to the "rand state" value,
looking values around 42 (35 to 50) I have

35, 37, 40, 41, 43, 45, 46, 49, 50
all tests are fine

36, 39 , 47
almost all tests are fine, just need

assert (s,ones (6, 1),2 * eps)
changed to
assert (s,ones (6, 1),3 * eps)  # or 4*

as "maximum absolute error 6.66134e-16 exceeds tolerance 4.44089e-16"

the other values (38, 42, 44, 48 ) fails the sigma=0 test or
I get

assert (flag,!1) expected
0
but got
 1

already at the first test.
Is it possible that rand/randn are not producing the same value
on all the system, eventually due to different rounding ?

Regards
Marco


reply via email to

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