Octave 3.2.2/3.2.3 failures of eig/eigs during make check

[Cyrus Hall]

Ciao all-

I have tried to build both Octave 3.2.2 and 3.2.3 from source on Ubuntu
9.04, as the 3.0 does not contain functionality I desire (mainly, good
support for sparse matrices).  Unfortunately, both builds fail the same
number of tests when make check is run:

...
src/DLD-FUNCTIONS/eig.cc ............................... PASS   15/20
FAIL 5
src/DLD-FUNCTIONS/eigs.cc .............................. PASS   99/149
FAIL 50
...

In my search of the list I did not find similar reports.  A few of the
failures appear trivial, and possibly not important.  For example:

 A = [1, 2; -1, 1]; B = [3, 3; 1, 2];
 [v, d] = eig (A, B);
 assert(A * v(:, 1), d(1, 1) * B * v(:, 1), sqrt (eps));
 assert(A * v(:, 2), d(2, 2) * B * v(:, 2), sqrt (eps));
!!!!! test failed
assert (A * v (:, 1),d (1, 1) * B * v (:, 1),sqrt (eps)) expected
   1.5000 + 0.0000i
   1.5000 + 0.0000i
but got
   1.5000 - 0.0000i
   1.5000 - 0.0000i
maximum absolute error 2.93328e-08 exceeds tolerance 1.49012e-08  *****
test

However, the majority appear a little bit more serious:

 A = [1+3i, 2+i; 2-i, 1+3i]; B = [5+9i, 2+i; 2-i, 5+9i];
 [v, d] = eig (A, B);
 assert(A * v(:, 1), d(1, 1) * B * v(:, 1), sqrt (eps));
 assert(A * v(:, 2), d(2, 2) * B * v(:, 2), sqrt (eps));
!!!!! test failed
assert (A * v (:, 1),d (1, 1) * B * v (:, 1),sqrt (eps)) expected
    505.39 -  185.76i
  -1489.28 + 1353.70i
but got
   1.11867 - 0.17754i
   0.11721 + 2.41487i
maximum absolute error 2011.04 exceeds tolerance 1.49012e-08  ***** test

In the case of the eigs failures, all the messages are of the form

  eigs: error -9999 in xxxxxx

where xxxxxx is something is either znaupd or dsaupd.  This feels like a
linking issue, or maybe a version issue, yet 99 of the tests pass.

The build of both versions fairly normal.  I'm using the ubuntu provided
versions of all dependencies, and did not provide qrupdate.  Indeed, I
don't know how slow the old QR routines are, but that section of make
test script does not seem to ever finish.  The log of the tests that do
finish is posted at

  http://www.inf.unisi.ch/phd/hall/octave-3.2.3-make-test.log

The 3.2.2 log is at

  http://www.inf.unisi.ch/phd/hall/octave-3.2.2-make-test.log

There are only slight difference, which diff shows handily.  That 3.2.2
build *was* built with qrupdate.

Both builds and test runs were performed on a Intel Core Duo.  Configure
was called with:

LDFLAGS="-lmetis" ./configure --prefix=/home/hallcp/sw --enable-shared

as metis was not correctly linking when make tried to create the final
octave binary.

I am more than willing to provide more details as I would love to have a
eigs (and eig) that pass all tests.

Cheers,
Cyrus Hall
University of Lugano


_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Cyrus Hall]

I had not noticed until just now that some of the tests do not fail with
the same incorrect values each time they are run:

octave:1>  A = [1+3i, 2+i; 2-i, 1+3i]; B = [5+9i, 2+i; 2-i, 5+9i];
octave:2>  [v, d] = eig (A, B);
octave:3>  assert(A * v(:, 1), d(1, 1) * B * v(:, 1), sqrt (eps));
error: assert (A * v (:, 1),d (1, 1) * B * v (:, 1),sqrt (eps)) expected
  -5.1989 + 1.5530i
  -3.7537 + 1.7986i
but got
  -2.3455 - 3.3422i
  -2.4744 - 1.3489i
maximum absolute error 5.66616 exceeds tolerance 1.49012e-08
error: called from:
error:   /home/hallcp/sw/share/octave/3.2.3/m/testfun/assert.m at line
209, column 5
octave:3>  assert(A * v(:, 2), d(2, 2) * B * v(:, 2), sqrt (eps));
error: assert (A * v (:, 2),d (2, 2) * B * v (:, 2),sqrt (eps)) expected
   1.8875 - 1.1145i
  -1.9578 + 0.7916i
but got
  -0.5970 + 2.1114i
   1.1474 - 3.3054i
maximum absolute error 5.14083 exceeds tolerance 1.49012e-08
error: called from:
error:   /home/hallcp/sw/share/octave/3.2.3/m/testfun/assert.m at line
209, column 5

But then if I restart Octave 3.2.3 and try again...

octave:1>  A = [1+3i, 2+i; 2-i, 1+3i]; B = [5+9i, 2+i; 2-i, 5+9i];
octave:2>  [v, d] = eig (A, B);
octave:3>  assert(A * v(:, 1), d(1, 1) * B * v(:, 1), sqrt (eps));
error: assert (A * v (:, 1),d (1, 1) * B * v (:, 1),sqrt (eps)) expected
  -5.2519 + 1.6063i
  -3.8228 + 1.8480i
but got
  -2.3842 - 3.3836i
  -2.5070 - 1.3848i
maximum absolute error 5.75526 exceeds tolerance 1.49012e-08
error: called from:
error:   /home/hallcp/sw/share/octave/3.2.3/m/testfun/assert.m at line
209, column 5
octave:3>  assert(A * v(:, 2), d(2, 2) * B * v(:, 2), sqrt (eps));
error: assert (A * v (:, 2),d (2, 2) * B * v (:, 2),sqrt (eps)) expected
   1.9083 - 1.1113i
  -1.9813 + 0.7892i
but got
  -0.6050 + 2.1255i
   1.1543 - 3.3355i
maximum absolute error 5.18123 exceeds tolerance 1.49012e-08
error: called from:
error:   /home/hallcp/sw/share/octave/3.2.3/m/testfun/assert.m at line
209, column 5

I assume this could be due to some sort of random initialization in
ARPACK, but it would seem that any difference in the final result should
be smaller than sqrt(eps).

Cheers,
Cyrus

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Jaroslav Hajek-2]

On Mon, Sep 28, 2009 at 11:05 AM, Cyrus Hall <hallc@...> wrote:

> I had not noticed until just now that some of the tests do not fail with
> the same incorrect values each time they are run:
>
> octave:1>  A = [1+3i, 2+i; 2-i, 1+3i]; B = [5+9i, 2+i; 2-i, 5+9i];
> octave:2>  [v, d] = eig (A, B);
> octave:3>  assert(A * v(:, 1), d(1, 1) * B * v(:, 1), sqrt (eps));
> error: assert (A * v (:, 1),d (1, 1) * B * v (:, 1),sqrt (eps)) expected
>  -5.1989 + 1.5530i
>  -3.7537 + 1.7986i
> but got
>  -2.3455 - 3.3422i
>  -2.4744 - 1.3489i
> maximum absolute error 5.66616 exceeds tolerance 1.49012e-08
> error: called from:
> error:   /home/hallcp/sw/share/octave/3.2.3/m/testfun/assert.m at line
> 209, column 5
> octave:3>  assert(A * v(:, 2), d(2, 2) * B * v(:, 2), sqrt (eps));
> error: assert (A * v (:, 2),d (2, 2) * B * v (:, 2),sqrt (eps)) expected
>   1.8875 - 1.1145i
>  -1.9578 + 0.7916i
> but got
>  -0.5970 + 2.1114i
>   1.1474 - 3.3054i
> maximum absolute error 5.14083 exceeds tolerance 1.49012e-08
> error: called from:
> error:   /home/hallcp/sw/share/octave/3.2.3/m/testfun/assert.m at line
> 209, column 5
>
> But then if I restart Octave 3.2.3 and try again...
>
> octave:1>  A = [1+3i, 2+i; 2-i, 1+3i]; B = [5+9i, 2+i; 2-i, 5+9i];
> octave:2>  [v, d] = eig (A, B);
> octave:3>  assert(A * v(:, 1), d(1, 1) * B * v(:, 1), sqrt (eps));
> error: assert (A * v (:, 1),d (1, 1) * B * v (:, 1),sqrt (eps)) expected
>  -5.2519 + 1.6063i
>  -3.8228 + 1.8480i
> but got
>  -2.3842 - 3.3836i
>  -2.5070 - 1.3848i
> maximum absolute error 5.75526 exceeds tolerance 1.49012e-08
> error: called from:
> error:   /home/hallcp/sw/share/octave/3.2.3/m/testfun/assert.m at line
> 209, column 5
> octave:3>  assert(A * v(:, 2), d(2, 2) * B * v(:, 2), sqrt (eps));
> error: assert (A * v (:, 2),d (2, 2) * B * v (:, 2),sqrt (eps)) expected
>   1.9083 - 1.1113i
>  -1.9813 + 0.7892i
> but got
>  -0.6050 + 2.1255i
>   1.1543 - 3.3355i
> maximum absolute error 5.18123 exceeds tolerance 1.49012e-08
> error: called from:
> error:   /home/hallcp/sw/share/octave/3.2.3/m/testfun/assert.m at line
> 209, column 5
>
> I assume this could be due to some sort of random initialization in
> ARPACK, but it would seem that any difference in the final result should
> be smaller than sqrt(eps).
>
> Cheers,
> Cyrus
>
> _______________________________________________
> Bug-octave mailing list
> Bug-octave@...
> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
>

This looks like the known problem of mislinked LAPACK vs. ARPACK. If
you build without ARPACK (configure --without-arpack),
do you still see the problem in eig?
The solution was to rebuild ARPACK against LAPACK 3 no matter what the
ARPACK manual says.

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

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Cyrus Hall]

On Tue, 2009-09-29 at 07:18 +0200, Jaroslav Hajek wrote:
> On Mon, Sep 28, 2009 at 11:05 AM, Cyrus Hall <hallc@...> wrote:
> > I had not noticed until just now that some of the tests do not fail with
> > the same incorrect values each time they are run.
>
> This looks like the known problem of mislinked LAPACK vs. ARPACK. If
> you build without ARPACK (configure --without-arpack),
> do you still see the problem in eig?
> The solution was to rebuild ARPACK against LAPACK 3 no matter what the
> ARPACK manual says.

I built without arpack and the problem remains.  The same tests fail,
and the values continue to change each time eig is called.

Any other ideas?

Cheers,
Cyrus

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Jaroslav Hajek-2]

On Tue, Sep 29, 2009 at 1:17 PM, Cyrus Hall <hallc@...> wrote:

> On Tue, 2009-09-29 at 07:18 +0200, Jaroslav Hajek wrote:
>> On Mon, Sep 28, 2009 at 11:05 AM, Cyrus Hall <hallc@...> wrote:
>> > I had not noticed until just now that some of the tests do not fail with
>> > the same incorrect values each time they are run.
>>
>> This looks like the known problem of mislinked LAPACK vs. ARPACK. If
>> you build without ARPACK (configure --without-arpack),
>> do you still see the problem in eig?
>> The solution was to rebuild ARPACK against LAPACK 3 no matter what the
>> ARPACK manual says.
>
> I built without arpack and the problem remains.  The same tests fail,
> and the values continue to change each time eig is called.
>
> Any other ideas?
>
> Cheers,
> Cyrus
>

Can you send your config.log from the latter build?

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

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Jaroslav Hajek-2]

On Tue, Sep 29, 2009 at 1:21 PM, Jaroslav Hajek <highegg@...> wrote:

> On Tue, Sep 29, 2009 at 1:17 PM, Cyrus Hall <hallc@...> wrote:
>> On Tue, 2009-09-29 at 07:18 +0200, Jaroslav Hajek wrote:
>>> On Mon, Sep 28, 2009 at 11:05 AM, Cyrus Hall <hallc@...> wrote:
>>> > I had not noticed until just now that some of the tests do not fail with
>>> > the same incorrect values each time they are run.
>>>
>>> This looks like the known problem of mislinked LAPACK vs. ARPACK. If
>>> you build without ARPACK (configure --without-arpack),
>>> do you still see the problem in eig?
>>> The solution was to rebuild ARPACK against LAPACK 3 no matter what the
>>> ARPACK manual says.
>>
>> I built without arpack and the problem remains.  The same tests fail,
>> and the values continue to change each time eig is called.
>>
>> Any other ideas?
>>
>> Cheers,
>> Cyrus
>>
>
> Can you send your config.log from the latter build?
>

Btw., these files are usually huge, so either use a pastebin service
(pastebin.cz, pastebin.ca, pastebin.com...) or compress it.


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

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Cyrus Hall]

On Tue, 2009-09-29 at 13:21 +0200, Jaroslav Hajek wrote:

> On Tue, Sep 29, 2009 at 1:17 PM, Cyrus Hall <hallc@...> wrote:
> > On Tue, 2009-09-29 at 07:18 +0200, Jaroslav Hajek wrote:
> >> On Mon, Sep 28, 2009 at 11:05 AM, Cyrus Hall <hallc@...> wrote:
> >> > I had not noticed until just now that some of the tests do not fail with
> >> > the same incorrect values each time they are run.
> >>
> >> This looks like the known problem of mislinked LAPACK vs. ARPACK. If
> >> you build without ARPACK (configure --without-arpack),
> >> do you still see the problem in eig?
> >> The solution was to rebuild ARPACK against LAPACK 3 no matter what the
> >> ARPACK manual says.
> >
> > I built without arpack and the problem remains.  The same tests fail,
> > and the values continue to change each time eig is called.
> >
> > Any other ideas?
> >
> > Cheers,
> > Cyrus
> >
>
> Can you send your config.log from the latter build?

Sure. I've posted it at:

http://www.inf.unisi.ch/phd/hall/octave-3.2.3-noarpack-config.log

Cheers,
Cyrus

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Jaroslav Hajek-2]

On Tue, Sep 29, 2009 at 1:43 PM, Cyrus Hall <hallc@...> wrote:

> On Tue, 2009-09-29 at 13:21 +0200, Jaroslav Hajek wrote:
>> On Tue, Sep 29, 2009 at 1:17 PM, Cyrus Hall <hallc@...> wrote:
>> > On Tue, 2009-09-29 at 07:18 +0200, Jaroslav Hajek wrote:
>> >> On Mon, Sep 28, 2009 at 11:05 AM, Cyrus Hall <hallc@...> wrote:
>> >> > I had not noticed until just now that some of the tests do not fail with
>> >> > the same incorrect values each time they are run.
>> >>
>> >> This looks like the known problem of mislinked LAPACK vs. ARPACK. If
>> >> you build without ARPACK (configure --without-arpack),
>> >> do you still see the problem in eig?
>> >> The solution was to rebuild ARPACK against LAPACK 3 no matter what the
>> >> ARPACK manual says.
>> >
>> > I built without arpack and the problem remains.  The same tests fail,
>> > and the values continue to change each time eig is called.
>> >
>> > Any other ideas?
>> >
>> > Cheers,
>> > Cyrus
>> >
>>
>> Can you send your config.log from the latter build?
>
> Sure. I've posted it at:
>
> http://www.inf.unisi.ch/phd/hall/octave-3.2.3-noarpack-config.log
>
> Cheers,
> Cyrus

I see nothing suspicious. If you have valgrind installed, please try

octave:1>  A = [1+3i, 2+i; 2-i, 1+3i]; B = [5+9i, 2+i; 2-i, 5+9i];
octave:2>  [v, d] = eig (A, B);

with ./run-octave -valgrind

and post all messages that appear *after* the initial prompt. This can
discover whether you're having an invalid memory access.

hth

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

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Cyrus Hall]

On Tue, 2009-09-29 at 13:53 +0200, Jaroslav Hajek wrote:

> I see nothing suspicious. If you have valgrind installed, please try
>
> octave:1>  A = [1+3i, 2+i; 2-i, 1+3i]; B = [5+9i, 2+i; 2-i, 5+9i];
> octave:2>  [v, d] = eig (A, B);
>
> with ./run-octave -valgrind
>
> and post all messages that appear *after* the initial prompt. This can
> discover whether you're having an invalid memory access.
>
> hth

Wow, the number of jumps that depend on uninitialized values in LAPACK
is concerning.  The output was so large that I've uploaded it:

http://www.inf.unisi.ch/phd/hall/octave-3.2.3-valgrind

Note that the input is not listed in the dump as it was piped to octave
via redirection.  The script consists of your two suggested lines:

A = [1+3i, 2+i; 2-i, 1+3i]; B = [5+9i, 2+i; 2-i, 5+9i];
[v, d] = eig (A, B);

All of the output after the octave prints the header comes after the
second line in the script is executed.

Cheers,
Cyrus

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Jaroslav Hajek-2]

On Tue, Sep 29, 2009 at 2:37 PM, Cyrus Hall <hallc@...> wrote:

> On Tue, 2009-09-29 at 13:53 +0200, Jaroslav Hajek wrote:
>> I see nothing suspicious. If you have valgrind installed, please try
>>
>> octave:1>  A = [1+3i, 2+i; 2-i, 1+3i]; B = [5+9i, 2+i; 2-i, 5+9i];
>> octave:2>  [v, d] = eig (A, B);
>>
>> with ./run-octave -valgrind
>>
>> and post all messages that appear *after* the initial prompt. This can
>> discover whether you're having an invalid memory access.
>>
>> hth
>
> Wow, the number of jumps that depend on uninitialized values in LAPACK
> is concerning.  The output was so large that I've uploaded it:
>
> http://www.inf.unisi.ch/phd/hall/octave-3.2.3-valgrind
>
> Note that the input is not listed in the dump as it was piped to octave
> via redirection.  The script consists of your two suggested lines:
>
> A = [1+3i, 2+i; 2-i, 1+3i]; B = [5+9i, 2+i; 2-i, 5+9i];
> [v, d] = eig (A, B);
>
> All of the output after the octave prints the header comes after the
> second line in the script is executed.
>
> Cheers,
> Cyrus
>
>

Sorry for the late reply. Unfortunately, I'm out of ideas. I suggest
you try with a different BLAS and LAPACK to see if the problem
persists.


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

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Jean-Francois Cardoso]

Jaroslav Hajek-2 wrote:

Sorry for the late reply. Unfortunately, I'm out of ideas. I suggest
you try with a different BLAS and LAPACK to see if the problem
persists.

I had similar problems.  I just discovered that they were due to a miscompiled
atlas package for SSE2 in Ubuntu repositories.
I fixed the issue by replacing the atlas/sse2 packages by generic atlas packages.

This seems to be a known issue:
  https://bugs.launchpad.net/ubuntu/+source/atlas/+bug/406520
  https://bugs.launchpad.net/ubuntu/+source/atlas/+bug/363510

Cheers, JF

[Cyrus Hall]

I can confirm that removing the SEE2 optimized version fixed the problem
and that all tests now pass.  Thanks for pointing me toward the proper
bug.

This is a serious bug to have gone unfixed for nearly half a year!  I
wonder how many published papers contain useless results because of
this.  Scary.

Has anyone thought about integrating a check for a broken atlas in
configure?  This is serious enough that it may be worth checking to
assure the integrity of the final build.  It would also prompt whoever
maintains Octave for various distributions to assure they had packaged a
fixed version of atlas.

Cheers,
Cyrus

On Tue, 2009-10-06 at 12:11 +0200, Jean-Francois Cardoso wrote:

>
>
> Jaroslav Hajek-2 wrote:
> >
> > Sorry for the late reply. Unfortunately, I'm out of ideas. I suggest
> > you try with a different BLAS and LAPACK to see if the problem
> > persists.
> >
>
> I had similar problems.  I just discovered that they were due to a
> miscompiled
> atlas package for SSE2 in Ubuntu repositories.
> I fixed the issue by replacing the atlas/sse2 packages by generic atlas
> packages.
>
> This seems to be a known issue:
>   https://bugs.launchpad.net/ubuntu/+source/atlas/+bug/406520
>   https://bugs.launchpad.net/ubuntu/+source/atlas/+bug/363510
>
> Cheers, JF
>

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Jaroslav Hajek-2]

On Tue, Oct 6, 2009 at 3:04 PM, Cyrus Hall <hallc@...> wrote:

> I can confirm that removing the SEE2 optimized version fixed the problem
> and that all tests now pass.  Thanks for pointing me toward the proper
> bug.
>
> This is a serious bug to have gone unfixed for nearly half a year!  I
> wonder how many published papers contain useless results because of
> this.  Scary.
>
> Has anyone thought about integrating a check for a broken atlas in
> configure?  This is serious enough that it may be worth checking to
> assure the integrity of the final build.  It would also prompt whoever
> maintains Octave for various distributions to assure they had packaged a
> fixed version of atlas.
>
> Cheers,
> Cyrus
>

Since both BLAS and LAPACK test suites exist, I think it is fairly
unnecessary. As you can see, the final Octave test suite can reveal
such errors. Also, rebuilding Octave with generic BLAS/LAPACK is
trivial. The main lesson for me (and maybe for you) is that broken
ATLAS is not an uncommon source of problems.

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

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[John W. Eaton-3]

On  6-Oct-2009, Cyrus Hall wrote:

| Has anyone thought about integrating a check for a broken atlas in
| configure?

What is the simplest reliable check?

If the problem is the same as the one we discussed here recently:

  https://www-old.cae.wisc.edu/pipermail/help-octave/2009-August/015913.html

(also follow the link to the other thread referenced in that message)
then the problem is really that the machine constants like eps were
calculated incorrectly.

Previously, when this happend, Octave would just issue a warning.  In
the current sources, it is a fatal error.  The patch I checked in is
here:

  http://hg.savannah.gnu.org/hgweb/octave/rev/264fb5520973

If the bug is the same, then when you started your copy of Octave
linked with the miscompiled ATLAS, did you get a warning about
"unrecognized floating point format"?  Did you ignore it?

jwe
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Cyrus Hall]

On Tue, 2009-10-06 at 15:16 +0200, John W. Eaton wrote:
> On  6-Oct-2009, Cyrus Hall wrote:
>
> | Has anyone thought about integrating a check for a broken atlas in
> | configure?
>
> What is the simplest reliable check?

No idea.  I frankly know nothing about these libraries as an end-user of
octave and other mathematics platforms.  That said, there does appear to
be a simple test posted on the ubuntu bug reports that Jean-Francois
linked to:

https://bugs.launchpad.net/ubuntu/+source/atlas/+bug/406520

> If the problem is the same as the one we discussed here recently:
>
>   https://www-old.cae.wisc.edu/pipermail/help-octave/2009-August/015913.html
>
> (also follow the link to the other thread referenced in that message)
> then the problem is really that the machine constants like eps were
> calculated incorrectly.
>
> Previously, when this happend, Octave would just issue a warning.  In
> the current sources, it is a fatal error.  The patch I checked in is
> here:
>
>   http://hg.savannah.gnu.org/hgweb/octave/rev/264fb5520973
>
> If the bug is the same, then when you started your copy of Octave
> linked with the miscompiled ATLAS, did you get a warning about
> "unrecognized floating point format"?  Did you ignore it?

I did not get this warning.  I believe my problem was related to the
SSE2 optimization problem, as removing that package immediately fixed
the issue.

Cheers,
Cyrus

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[John W. Eaton-3]

On  6-Oct-2009, Jaroslav Hajek wrote:

| Since both BLAS and LAPACK test suites exist, I think it is fairly
| unnecessary.

I agree.  I think it would be better to add or improve the tests for
lapack/blas in the lapack/blas package itself.  Or does Octave have to
take on the role of testing for all the packages it depends on?n

jwe
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Cyrus Hall]

On Tue, 2009-10-06 at 15:15 +0200, Jaroslav Hajek wrote:
> Since both BLAS and LAPACK test suites exist, I think it is fairly
> unnecessary. As you can see, the final Octave test suite can reveal
> such errors. Also, rebuilding Octave with generic BLAS/LAPACK is
> trivial. The main lesson for me (and maybe for you) is that broken
> ATLAS is not an uncommon source of problems.

While make check does a great job of finding the problem, it does not
diagnose it, leaving the user unable to proceed.  

My hours of google searching and browsing through bug reports did not
turn up the problem.  As such, I would conclude figuring out what is
wrong when one sees failures in eig, eigs, and an apparent infinite loop
in the qr tests, is difficult at best.  Since this particular problem
seems to be fairly easy to find (see my reply to John), it might be
worth the effort.

Cheers,
Cyrus

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Jaroslav Hajek-2]

On Tue, Oct 6, 2009 at 3:47 PM, Cyrus Hall <hallc@...> wrote:

> On Tue, 2009-10-06 at 15:15 +0200, Jaroslav Hajek wrote:
>> Since both BLAS and LAPACK test suites exist, I think it is fairly
>> unnecessary. As you can see, the final Octave test suite can reveal
>> such errors. Also, rebuilding Octave with generic BLAS/LAPACK is
>> trivial. The main lesson for me (and maybe for you) is that broken
>> ATLAS is not an uncommon source of problems.
>
> While make check does a great job of finding the problem, it does not
> diagnose it, leaving the user unable to proceed.
>

Yeah, it would be really marvelous if software always told you how to
proceed when you run into problems. Just like Star Trek.

>
> My hours of google searching and browsing through bug reports did not
> turn up the problem.

Maybe you were the first to observe it, or others did but did not
leave footprints.

> As such, I would conclude figuring out what is
> wrong when one sees failures in eig, eigs, and an apparent infinite loop
> in the qr tests, is difficult at best.

I would not quite say so. Next time, I will suggest replacing ATLAS as
the first attempt when facing this kind of problem.

>  Since this particular problem
> seems to be fairly easy to find (see my reply to John), it might be
> worth the effort.

If you really think it is worth your effort - I do not object to a
basic configure test for working BLAS. Just remember that configure
tests should be reasonably fast and not much memory consuming.

regards

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

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Jaroslav Hajek-2]

On Tue, Oct 6, 2009 at 3:46 PM, John W. Eaton <jwe@...> wrote:

> On  6-Oct-2009, Jaroslav Hajek wrote:
>
> | Since both BLAS and LAPACK test suites exist, I think it is fairly
> | unnecessary.
>
> I agree.  I think it would be better to add or improve the tests for
> lapack/blas in the lapack/blas package itself.  Or does Octave have to
> take on the role of testing for all the packages it depends on?n
>
> jwe
>

As a side note, Octave in fact *does* make a fairly good testbed, both
for the dependent libraries and compilers used.
It's just we of course can't test everything in the configure script.

Thinking about this, however, maybe it would be nice if there was some
information about what relevant libraries might be broken if a
function is not working, such as
linear algebra -> BLAS, LAPACK
sparse algebra -> SuiteSparse
eigs, svds -> ARPACK
convhull, delaunay,... -> Qhull
qrupdate,cholupdate,.. -> qrupdate
regexp -> pcre
etc.

of course, one can always ask on the list, which is a good idea anyway...

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

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave

[Cyrus Hall]

On Tue, 2009-10-06 at 16:03 +0200, Jaroslav Hajek wrote:

> On Tue, Oct 6, 2009 at 3:47 PM, Cyrus Hall <hallc@...> wrote:
> > On Tue, 2009-10-06 at 15:15 +0200, Jaroslav Hajek wrote:
> >> Since both BLAS and LAPACK test suites exist, I think it is fairly
> >> unnecessary. As you can see, the final Octave test suite can reveal
> >> such errors. Also, rebuilding Octave with generic BLAS/LAPACK is
> >> trivial. The main lesson for me (and maybe for you) is that broken
> >> ATLAS is not an uncommon source of problems.
> >
> > While make check does a great job of finding the problem, it does not
> > diagnose it, leaving the user unable to proceed.
> >
>
> Yeah, it would be really marvelous if software always told you how to
> proceed when you run into problems. Just like Star Trek.

I don't really appreciate this response.  I was arguing that it might be
important to make sure Octave is built such that it produces accurate
results.  You respond by insinuating that I'm just lazy.  Not a great
way to recruit people to help.

Maybe I'm taking this a little too seriously, but it seems like this
would be a common configuration problem under builds of octave on 32-bit
Ubuntu.  As a researcher, that deeply concerns me, as I know many of my
colleagues both work on that platform and are less careful about
checking for problems in the software they use.  A warning on the
download page would at least be a step in the right direction.

That said, I do understand being reluctant to check for what amounts to
someone else's bug, which will ideally be fixed sooner than later.  As
such, I will try and push on the Ubuntu side.  They have been packaging
atlas 3.6.0 for four releases now, a version which is now five years out
of date.  Time to get them to move forward.

Cheers,
Cyrus

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave