Re: ARPACK for 3.6.0

[Rik]

On 12/15/2011 08:11 AM, John W. Eaton wrote:
> 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.
There was a lot of work done on this problem.  See the bug report at
(https://savannah.gnu.org/bugs/?31479)
> | 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.
I'm attaching an amended script from the original bug report.  I
benchmarked the for loop and on octave-3.2.4 it segfaults after a mean
number of 7 trials.  99.9% of the distribution is less than 32, but the
maximum value I ever saw was 47.  Accordingly, I set the test threshold at
50.  On octave-3.5.90+ the 50 iterations take 0.2 seconds so there isn't
significant overhead in adding this to the test suite.

--Rik

bad_arpack.m
Description: Text Data