[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ANN: LAPACK and ScaLAPACK new functionality survey
From: |
Etienne Grossmann |
Subject: |
Re: ANN: LAPACK and ScaLAPACK new functionality survey |
Date: |
Wed, 2 Jun 2004 09:50:22 -0400 |
User-agent: |
Mutt/1.4.2.1i |
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