[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