Thu 30 Nov 2017 12:51:18 AM UTC, comment #34:
E.g.:
>>>>> processing /scratch/buildbot/slaves/jwe-debian-x86_64-0/clang-4_0-debian/src/scripts/sparse/eigs.m
A = toeplitz ([-2, 1, zeros(1, 8)]);
A = kron (A, eye (10)) + kron (eye (10), A);
opts.v0 = (1:100)';
opts.maxit = 3;
warning ("off", "Octave:eigs:UnconvergedEigenvalues", "local");
d = eigs (A, 4, "lm", opts);
assert (d(2:4), [NaN; NaN; NaN]);
!!!!! test failed
ASSERT errors for: assert (d (2:4),[NaN; NaN; NaN])
Location | Observed | Expected | Reason
(1) -7.365 NaN 'NaN' mismatch
A = toeplitz ([-2, 1, zeros(1, 8)]);
A = kron (A, eye (10)) + kron (eye (10), A);
Afun = @(x) A * x;
opts.v0 = (1:100)';
opts.maxit = 3;
opts.issym = true;
warning ("off", "Octave:eigs:UnconvergedEigenvalues", "local");
d = eigs (Afun, 100, 4, "sm", opts);
assert (d(2:4), [NaN; NaN; NaN]);
!!!!! test failed
ASSERT errors for: assert (d (2:4),[NaN; NaN; NaN])
Location | Observed | Expected | Reason
(1) -0.13578 NaN 'NaN' mismatch
A = magic (100);
opts.v0 = (1:100)';
opts.maxit = 1;
warning ("off", "Octave:eigs:UnconvergedEigenvalues", "local");
d = eigs (A, 4, "lm", opts);
assert (d(4), NaN);
!!!!! test failed
ASSERT errors for: assert (d (4),NaN)
Location | Observed | Expected | Reason
() 3.8548e-11 NaN 'NaN' mismatch
A = magic (100) / 100 + eye (100);
opts.v0 = (1:100)';
opts.maxit = 1;
warning ("off", "Octave:eigs:UnconvergedEigenvalues", "local");
d = eigs (A, 4, "sm", opts);
assert (d(3:4), [NaN+1iNaN; NaN+1iNaN]);
!!!!! test failed
eigs: error -14 in dneupd
A = 1i * magic (100) / 100 + eye (100);
opts.v0 = (1:100)';
opts.maxit = 1;
warning ("off", "Octave:eigs:UnconvergedEigenvalues", "local");
d = eigs (A, 4, "sm", opts);
assert (d(2:4), [NaN+1iNaN; NaN+1iNaN; NaN+1i*NaN]);
!!!!! test failed
eigs: error -14 in zneupd
|
Thu 30 Nov 2017 12:42:20 AM UTC, comment #33:
I am away from my computer -- but look at the buildbots, all of them are failing...
Dmitri.
|
Thu 30 Nov 2017 12:17:53 AM UTC, comment #32:
Works for me.
This is with 24337:999b167e5b4a.
|
Wed 29 Nov 2017 11:06:04 PM UTC, comment #31:
Bunch of eigs tests are failing
See: http://buildbot.octave.org:8010/waterfall
Dmitri.
|
Wed 29 Nov 2017 09:48:30 PM UTC, comment #30:
Great! I pushed the final changeset here http://hg.savannah.gnu.org/hgweb/octave/rev/0771ce2d30ef.
|
Wed 29 Nov 2017 09:13:37 PM UTC, comment #29:
@Rik: The patch (file #42524) lets me go on as before. Thank you for that and please push that one as well! Most of the FORTRAN checks don't need that save&restore as they do not really compile any FORTRAN source code.
Just for the files: my prior workaround (comment #26) did not work. Using "-fdefault-integer-8" within the FFLAGS causes liboctave/external/ranlib (all FORTRAN) to be compiled with INTEGER == uint64_t and messes up all RNGs that rely on 32 bit integers... It really raises some doubts about the reliability of Octave's FORTRAN heritage, but that is for another bug report.
Yesterday there were unnoticed errors.
|
Wed 29 Nov 2017 07:19:50 PM UTC, comment #28:
I checked in the fix that disabled ARPACK, rather than merely warning about it being buggy, here (http://hg.savannah.gnu.org/hgweb/octave/rev/740c6a7db92a).
@Kai: Can you try the attached patch integer8.diff? In it I simply add F77_INTEGER_8_FLAG to FFLAGS before compiling the Fortran code. This is the right thing to do, I just didn't think about it because I don't do much with Fortran. If you report it working then I'll commit that change as well.
That should be all you need to do to see whether it worked.
(file #42524)
|
Wed 29 Nov 2017 08:55:50 AM UTC, comment #27:
@Rik: yes, I can confirm that patch https://savannah.gnu.org/bugs/download.php?file_id=42507 fixes the linking issue I reported in comment #22 https://savannah.gnu.org/bugs/?func=detailitem&item_id=52425#comment22
|
Tue 28 Nov 2017 08:52:30 PM UTC, comment #26:
@Rik: after some more investigation, I found that the "F77_INTEGER_8_FLAG" is ignored by the new test of comment #20. But I think that after those many changes on configure and 64-bit indexing, that the original meaning [1] has changed anyway. The solution for me is to write "-fdefault-integer-8" in both "F77_INTEGER_8_FLAG" and "FFLAGS". In combination with you patch (file #42507) configure now works for me again, please push you patch.
[1] https://www.gnu.org/software/octave/doc/interpreter/Compiling-Octave-with-64_002dbit-Indexing.html
|
Tue 28 Nov 2017 05:33:05 PM UTC, comment #25:
@Kai: We prefer to test for capabilities, rather than version numbers, because version numbers can be unreliable. What if someone forks the ARPACK-ng codebase starting at version 3.0.0 and calls their library ARPACK-ng2 and starts with revision 1.0.0?
Does the diff I included in comment #23 help with your builds?
|
Tue 28 Nov 2017 04:47:05 PM UTC, comment #24:
Dear Rik, the new ARPACK test from changeset from comment #20 works fine for straight forward Octave 4.3.0+ compilation using ARPACK 3.5.0, but it no longer works for my 64-bit index "-fdefault-integer-8" compiled libraries.
A long story in short: Wasn't it possible to simply check for the ARPACK version and reject < 3.3.0? I do pass all the test-suite of ARPACK itself, but not the new one of Octave:
Even though you had a lot of work with refactoring the test in FORTRAN for Octave and merging (comment #20), it is a bug of ARPACK, it is tested there, so why should OCTAVE duplicate that test?
|
Tue 28 Nov 2017 12:21:38 AM UTC, comment #23:
Try the attached diff. If it works I'll convert it to a proper changeset.
(file #42507)
|
Mon 27 Nov 2017 08:27:03 PM UTC, comment #22:
After the recent configure changes for arpack,with the arpack 3.0.1 I had installed in stdout of configure script:
in config.log
So the detection seems to work as intended.
However during make arpack functions are not found:
the ARPACK related substitutions in the configure script are empty:
|
Wed 22 Nov 2017 07:12:40 AM UTC, comment #21:
@Rik: thanks. I put here the link to the original arpack bug
https://github.com/opencollab/arpack-ng/pull/19
as a reference.
|
Wed 22 Nov 2017 02:47:59 AM UTC, comment #20:
I put in testing for a bugy ARPACK library here http://hg.savannah.gnu.org/hgweb/octave/rev/f52d91f6ef80.
The merge of stable to default did not go well. I think I got it right in the end, but it was painful. We should encourage everyone that makes changes on stable to do the merge on to default immediately so someone who understands the code changes can correct any merge issues. In this case there were problems merging in Qt GUI code from Torsten that I had to work through without a real understanding.
|
Wed 22 Nov 2017 01:19:50 AM UTC, comment #19:
@jwe: The ARPACK version required is >= 3.3.0. In MXE build we use 3.5.0 so no problems there.
I think I can make the two checks in to one macro. I'll try anyways.
|
Tue 21 Nov 2017 10:29:09 PM UTC, comment #18:
Seems OK to me to test for this.
Is the version of ARPACK we use in mxe-octave OK?
Both OCTAVE_CHECK_LIB_ARPACK_OK and OCTAVE_CHECK_LIB_ARPACK_BUGGY both check for bugs, correct? Maybe these should be OCTAVE_CHECK_LIB_ARPACK_OK_1 and ..._OK_2 and OCTAVE_CHECK_LIB_ARPACK_OK could use these sub-macros? It's not critical, but it might make it easier to understand. If you don't have time, make a note of that in a comment for the original _OK function?
|
Tue 21 Nov 2017 10:17:30 PM UTC, comment #17:
Adding jwe to the CC list.
@jwe: There is already a macro in m4/acinclude.m4 (OCTAVE_CHECK_LIB_ARPACK_OK) which compiles and runs a C++ piece of code to determine if the ARPACK library is okay. I added a new macro OCTAVE_CHECK_LIB_ARPACK_BUGGY which compiles and runs a piece of Fortran code from Marco to determine if the ARPACK library works, but is buggy. Should this be committed before the 4.2.2 release?
The patch is attached.
(file #42454)
|
Tue 21 Nov 2017 07:56:21 PM UTC, comment #16:
The attached file bug_52425.f should do the job.
Another possibility is to use bug_1315_double.c from arpack
https://github.com/opencollab/arpack-ng/blob/master/TESTS/bug_1315_double.c
(file #42453)
|
Tue 21 Nov 2017 05:59:26 PM UTC, comment #15:
The preference is to test for features, rather than version numbers, in configure scripts.
It seems like the existing Fortran test code from Marco almost does that. If it could be converted into returning a 1 or 0 as an exit code, rather than printing results to stdout, then it could be wrapped in a configure test.
|
Tue 21 Nov 2017 09:27:23 AM UTC, comment #14:
This is a clear sign of the bug in arpack I mentioned: different eigenvalues when eigenvectors are required. So, please upgrade your arpack lib. The mistery now is why previous versions of octave did work. Maybe octave should warn during installation if arpack < 3.3.0 is found.
|
Tue 21 Nov 2017 08:40:17 AM UTC, comment #13:
Here the results for rvec true/false, that does have an impact:
|
Tue 21 Nov 2017 07:26:08 AM UTC, comment #12:
@arb: can you please set rvec = .false. in the fortran file and rerun it?
|
Mon 20 Nov 2017 07:42:15 PM UTC, comment #11:
@Marco: Perhaps no surprise since I have arpack-3.3.0, but running the Fortran program produced:
@A.R.: Really no idea why the dev version of Octave should be failing. Can you try upgrading libarpack?
|
Mon 20 Nov 2017 12:16:37 PM UTC, comment #10:
This is the output I get:
|
Mon 20 Nov 2017 11:30:01 AM UTC, comment #9:
This is very strange. Can you please try the attached fortran file? It reproduces the example. In order to compile and run it, I do
I get the eigenvalues 2.0810 with both arpack 3.3.0 and 3.0.
(file #42443)
|
Mon 20 Nov 2017 10:02:22 AM UTC, comment #8:
Setting:
gives
with octave-4.2.1 I obtain:
|
Mon 20 Nov 2017 07:25:42 AM UTC, comment #7:
@A.R. Burgers: first, I strongly suggest you to upgrade to arpack 3.3.0, at least. Before 3.2.0 arpack can compute wrong eigenvectors. Second, can you find an explicit initial vector for eigs for which the first two values of
are 5.6825? This would make the example exactly reproducible.
|
Sun 19 Nov 2017 06:34:52 PM UTC, comment #6:
Adding Marco Caliari to the CC list. It appears that this cset
which fixed other bugs in eigs, may have introduced one as well.
All of this works for me, but my arpack version is 3.3.0 while the reporter's is 3.0.1. That may also be critical.
|
Sun 19 Nov 2017 10:16:29 AM UTC, comment #5:
These are my lib versions:
|
Sun 19 Nov 2017 10:08:15 AM UTC, comment #4:
It goes wrong for me in r24228, r24227 is still OK
|
Fri 17 Nov 2017 07:14:58 PM UTC, comment #3:
Works for me. This is with hg id 24266:c372b091f622.
The changes below were checked in Nov. 11th and corrected some longstanding problems with eigs. You might want to see if the tests started to fail after one of these particular changesets.
|
Fri 17 Nov 2017 05:23:50 PM UTC, comment #2:
No I did not change the blas/lapack/arpack libraries. test eigs still passes in octave-4.2.1 with the same set of blas/lapack/arpack .so.
For dev the eigs test did still pass when I reported the colormap FAIL in https://savannah.gnu.org/bugs/?52358
|
Fri 17 Nov 2017 01:40:58 PM UTC, comment #1:
Works for me:
c372b091f622+ tip @
test eigs verbose
...
d1 = eigs (A, k, "be");
assert (d1, d2([1:floor(k/2), (end - ceil(k/2) + 1):end]), 1e-11);
...
PASSES 167 out of 167 tests
Also buildbots seem to be happy:
http://buildbot.octave.org:8010/waterfall
Did you update blas/lapack/arpack recently?
Dmitri.
--
|
Fri 17 Nov 2017 08:19:28 AM UTC, original submission:
calling test eigs results in 4 FAIL's since recently:
|