ARPACK and Qhull for 3.6.0

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

ARPACK and Qhull for 3.6.0

Rik-5
12/12/11

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
Program configure.ac to check for an external ARPACK which has the bug
fixes we need

Qhull
Modify configure.ac to detect versions < 2010 and versions > 2010
#ifdef in Qhull code to include the correctly named library

--Rik
Reply | Threaded
Open this post in threaded view
|

Qhull for 3.6.0

John W. Eaton
Administrator
On 12-Dec-2011, Rik wrote:

| Qhull
| Modify configure.ac to detect versions < 2010 and versions > 2010
| #ifdef in Qhull code to include the correctly named library

I don't think we want to check version numbers.  I checked in the
following change:

http://hg.savannah.gnu.org/hgweb/octave/rev/f913363318e0

Depending on how qhull is compiled, it may be necessary to define
qh_QHpointer=1 before including qhull.h.  I'd like to have a configure
test for that, but I don't know how to write it.  Either that, or I'd
like to have a way to avoid having to define a macro like that at all,
since it seems like an implementation detail of qhull that we should
not have to know about just to use qhull.

jwe
Reply | Threaded
Open this post in threaded view
|

ARPACK for 3.6.0

John W. Eaton
Administrator
In reply to this post by Rik-5
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.  So how can we check to be sure
that ARPACK has the bug fix(es) we need?

jwe
Reply | Threaded
Open this post in threaded view
|

Re: ARPACK for 3.6.0

Rik-4
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.  I was
thinking of just using library version numbers.

--Rik
>   So how can we check to be sure
> that ARPACK has the bug fix(es) we need?

Reply | Threaded
Open this post in threaded view
|

Re: ARPACK for 3.6.0

John W. Eaton
Administrator
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 | Threaded
Open this post in threaded view
|

Re: ARPACK for 3.6.0

Rik-4
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 (105 bytes) Download Attachment