octave-maintainers
[Top][All Lists]
Advanced

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

Re: ARPACK for 3.6.0


From: John W. Eaton
Subject: Re: ARPACK for 3.6.0
Date: Thu, 15 Dec 2011 11:11:45 -0500

On 13-Dec-2011, Rik wrote:

| On 12/13/2011 05:29 PM, John W. Eaton wrote:
| > On 12-Dec-2011, Rik wrote:
| >
| > | Was there any decision about how to handle ARPACK and Qhull for 3.6.0? 
| > | There is no bug report in the bug tracker for either item so they will
| > | currently be ignored as gating items for the release.  I see the following
| > | as possible actions.
| > | 
| > | ARPACK
| > | Remove ARPACK code from Mercurial control
| > | Point users to external release of ARPACK library
| >
| > This part I can do.
| >
| > | Program configure.ac to check for an external ARPACK which has the bug
| > | fixes we need
| >
| > I don't know how to write a test to do that reliably.  As I recall,
| > the failures were not predictable.
| I believe there was a specific matrix that would trigger the bug from a
| 2006 report (http://www.inf.usi.ch/phd/hall/core-matrix.oct).  But coding
| this up as a C or Fortran test doesn't seem like a lot of fun.

My initial reaction was to go ahead and write a test, but now I see
that it's a sparse matrix, so that makes it a bit more complicated.

| I was
| thinking of just using library version numbers. 

I'd rather avoid version numbers in autoconf checks if possible.

If it is not easy to generate a direct test for arpack, then how about
just adding at test to the test suite?  Do you have a link to the bug
report that goes along with that matrix?  Then at least people who run
the test suite will see a failure if they have a copy of arpack that
has the bug.  We could include some explanation in a comment with the
test.

jwe


reply via email to

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