[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?
etc.).
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:
<http://savannah.gnu.org/bugs/?46683>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/