Mon 09 May 2011 09:14:37 PM UTC, comment #6:
It seems that there could be possible competition at link time between your installed ARPACK and the one shipped with Octave.
I would remove the packages libarpack++2-dev libarpack++2c2a libarpack2 libarpack2-dev. Then I would do a full reset and recompile.
It's still very odd that this is failing. ARPACK is an iterative solver and the results depend on the initial position from where it starts the search. This is the reason for initializing the random number generator and always using the same starting point. That is the change I made that allowed this bug report to be closed the first time. We could move to a different initial seed (41 or 43 instead of 42), but this would mean verifying that the new seed doesn't create problems on other systems. In fact, if the complete rebuild fails I might suggest that we compare the value of the initial vector used on your system and on mine to see if they differ.
|
Mon 09 May 2011 07:20:45 PM UTC, comment #5:
Thank you for your reply.
I have removed:
re-ran configure && make but the test still fails. I have cropped the test to
If I change the rand state different to 42 (tried 41,43,44) the test passes:
please let me know if I can provide more informations. I also tried bisect but found no version which passes the test beginning from
|
Sun 08 May 2011 02:25:41 PM UTC, comment #4:
svds relies on eigs() and ARPACK. The 3.4.0 release did switch over from using an external ARPACK library to an internal, bug-corrected library, that is shipped in the liboctave directory. It might be worth removing any installed ARPACK library you have in case Octave is linking against the wrong copy. Also, you might want to take a look at using 'hg bisect' as an efficient way to narrow down the changeset which introduced the problem.
|
Sun 08 May 2011 08:25:27 AM UTC, comment #3:
Hi Rik, I'm on the default branch.
Änderung: 12649:8579e7a6e6e0
Vorgänger: 12644:e205ebe2ba67
Nutzer: Rik <octave@nomad.inbox5.com>
Datum: Thu May 05 16:58:43 2011 -0700
Zusammenfassung: Improve performance (2X) of svds by avoiding issymmetric calculation (bug #33073)
---same problem as in 52d79740a76c
Änderung: 12648:c6378cec77af
Zweig: stable
Nutzer: Marco Caliari -unavailable-
Datum: Wed May 04 20:34:10 2011 -0700
Zusammenfassung: Fix unfilled contourf when lvl = [0,0] (bug #33177).
---same problem as in 52d79740a76c
Änderung: 12517:c2e8c9d9e284
Nutzer: Rik <octave@nomad.inbox5.com>
Datum: Thu Mar 17 23:11:47 2011 -0700
Zusammenfassung: Fix bug #32818, nonconformant arguments in svds.
---same problem as in 52d79740a76c
Änderung: 12329:5f203b5bbf98
Nutzer: Rik <octave@nomad.inbox5.com>
Datum: Wed Feb 02 21:31:33 2011 -0800
Zusammenfassung: Use testif to only run some sparse tests when necessary libraries are installed.
---same problem as in 52d79740a76c
Änderung: 12195:d25dfa9ed18b
Nutzer: John W. Eaton <jwe@octave.org>
Datum: Fri Jan 28 14:05:09 2011 -0500
Zusammenfassung: remove configure checks for ARPACK
In d25dfa9ed18b, "test svds" prints a very long output without error message. I'll have a deeper look on this tomorrow.
Since the test is only executed if libumfpack is installed:
apt-cache policy libumfpack5.4.0
libumfpack5.4.0:
Installiert: 1:3.4.0-2
Kandidat: 1:3.4.0-2
Versionstabelle:
500 http://ftp.de.debian.org/debian/ sid/main i386 Packages
100 /var/lib/dpkg/status
Andy
|
Sun 08 May 2011 12:04:04 AM UTC, comment #2:
Are you on the stable or default branch?
What happens if you go back to the changeset one before this one,
changeset: 12649:8579e7a6e6e0
parent: 12644:e205ebe2ba67
user: Rik <octave@nomad.inbox5.com>
date: Thu May 05 16:58:43 2011 -0700
summary: Improve performance (2X) of svds by avoiding issymmetric calculation (bug #33073)
which is revision c6378cec77af? Does it work then?
|
Sat 07 May 2011 10:46:51 PM UTC, comment #1:
I compiled 52d79740a76c 20min ago with debian sid (gcc-4.6)
and "test svds" fails 100/100 because the first row is missing
octave:100> test svds
warning: returning fewer singular values than requested
warning: try increasing the value of sigma
***** testif HAVE_UMFPACK
[u2,s2,v2,flag] = svds(A,k,0,opts);
s2 = diag(s2);
assert(flag,!1);
assert(s2, s(k:-1:1), 1e-10);
!!!!! test failed
assert (s2,s (k:-1:1),1e-10) expected
38.060
38.034
38.034
38.015
38.015
38.004
38.004
but got
38.034
38.034
38.015
38.015
38.004
38.004
Dimensions don't match
|