[Top][All Lists]

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

[Octave-bug-tracker] [bug #46683] Need better configure test for bad ARP

From: Rik
Subject: [Octave-bug-tracker] [bug #46683] Need better configure test for bad ARPACK library
Date: Fri, 08 Jan 2016 20:31:10 +0000
User-agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1)

Follow-up Comment #18, bug #46683 (project octave):

@Marco: The configure test runs straight Fortran so if you have code that
fails on the bad libraries that is good enough.  We don't need to have it fail
in exactly the same way as in Octave proper.

But, does Octave succeed on a matrix that fails in straight Fortran?  If it
does then there may be no need to blacklist old versions of ARPACK.

For reference, eigs is probably the most complicated function in Octave.

The code begins in scripts/sparse/eigs.m where some input validation is done
and we handle the corner case of a small matrix which ARPACK does not do well.
 The m-file also formats the output returned from C++.

If it is an ordinary case it is forwarded to libinterp/dldfcn/__eigs__.cc. 
This also does input checking and then works to call the correct internal
function based on characteristics of the inputs (complex? function or matrix?

The code then shifts to liboctave/numeric/eigs-base.cc.  Here you will find
yet more input validation and a lot of code to prepare the inputs for
forwarding on to Fortran code.  Eventually a particular Fortran routine is
called and the results are passed back up the stack to the m-file.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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