Re: ANN: LAPACK and ScaLAPACK new functionality survey

[Etienne Grossmann]

  Hi all,

On Tue, Jun 01, 2004 at 09:55:56PM -0400, Paul Kienzle wrote:
# The only candidates that leap to mind are matrix sqrt, exp and log for 
# which

to my mind leaped incremental SVD. I.e. update the SVD (or part
thereof) of a matrix after adding/removing rows/columns.

# there are accurate algorithms which are not built upon diagonalization.
# There are also candidates in control systems, such as the discrete 
# Lyapunov
# solver  (a x a' - x + b = 0), which has a loop, but I don't know how 
# broadly
# useful it is.  Anyone care to put forward an argument for any of these?

  It could be worth it. I am quite ignorant of how Octave is affected
by LAPACK, though. John?

# I'm assuming that sparse methods are beyond the scope of LAPACK.

  Yes, but, from the lapack page http://www.netlib.org/scalapack/,
sparse seems to be within the scope of ScaLAPACK :

======================================================================
The ScaLAPACK project [snip] comprised four components:

    * dense and band matrix software (ScaLAPACK)
    * large sparse eigenvalue software (PARPACK and ARPACK)
    * sparse direct systems software (CAPSS and MFACT)
    * preconditioners for large sparse iterative solvers (ParPre) 

[snip]
======================================================================

  Just my 2c,

  Etienne

# And fft, filtering, convolution, optimization, special functions, 
# sorting,
# random number generation, quadrature, interpolation, ...
# 
# Paul Kienzle
# address@hidden
# 
# On Jun 1, 2004, at 5:30 PM, Jason Riedy wrote:
# 
# >[mailed jointly to address@hidden, address@hidden
# >to reach users with relevant experience.  watch where your replies
# >go.  what would make using LAPACK and ScaLAPACK easier for Octave
# >and R developers?  -- ejr, not subscribed]
# >
# >We plan to update the LAPACK and ScaLAPACK libraries and would like to 
# >have
# >feedback from users on what functionalities they think are missing and 
# >would
# >be needed in order to make these libraries more useful for the 
# >community. We
# >invite you to enter your suggestions in the form below. It would be 
# >most
# >useful to have input by June 16th, although we would welcome your 
# >input at
# >any time.
# >
# >Both LAPACK and ScaLAPACK provide well-tested, open source, reviewed 
# >code
# >implementing trusted algorithms that guarantee reliability, efficiency 
# >and
# >accuracy. Any new functionality must adhere to these standards and 
# >should
# >have a significant impact in order to justify the development costs. 
# >We are
# >also interested in suggestions regarding user interfaces, 
# >documentation,
# >language interfaces, target (parallel) architectures and other issues, 
# >again
# >provided the impact is large enough.
# >
# >We already plan to include a variety of improved algorithms discovered 
# >over
# >the years by a number of researchers (e.g. faster or more accurate
# >eigenvalue and SVD algorithms, extra precise iterative refinement, 
# >recursive
# >blocking for some linear solvers, etc.). We also know of a variety of 
# >other
# >possible functions we could add (e.g. updating and downdating
# >factorizations), but are uncertain of their impact.
# >
# >Please see http://icl.cs.utk.edu/lapack-survey.html for the survey.
# >We would like to have your input by June 16th, 2004.
# >
# >Regards,
# >Jack Dongarra, Jim Demmel, and Sven Hammarling
# >
# 

-- 
Etienne Grossmann ------ http://www.cs.uky.edu/~etienne