From maintainers-request at octave dot org Tue Dec 14 13:56:55 2004
Subject: started work on new version of LAPACK
From: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
To: Piotr Luszczek <luszczek at cs dot utk dot edu>
Cc: maintainers at octave dot org
Date: Tue, 14 Dec 2004 14:57:45 -0500

On 14-Dec-2004, Piotr Luszczek <luszczek at cs dot utk dot edu> wrote:

Hi Piotr,

Thanks for considering the Octave community in your plans.

| - programming language of new implementation (we will keep the old code
| as it is)

I know that some people would also like a more natural way of using
LAPACK from C/C++, but for Octave it would be best to keep the
column-major ordering of matrix elements.

With modern Fortran or C, it might be nice to provide an alternative
interface for each routine that needs work arrays so that those could
be omitted and allocated automatically.  But I don't think you would
want to eliminate the interface that accepts work arrays because there
are many cases when it is more efficient for the caller to allocate them.

If you choose to provide a C++ interface or really want to take
advantage of modern Fortran, then it would seem to be natural for the
LAPACK routines to work on matrix objects.  Then you could eliminate
the need for passing the leading dimension and row and column
dimensions separately from the data.  But since there is no standard
matrix object for C++, it might be a bit tricky to do this in a way
that will please very many people.

| - support for threading (OpenMP, pthreads, etc.)

Can you give some more details about what this would provide?

| - 64-bit addressing

This would be useful.  There is some work underway to allow Octave to
handle >2GB arrays.  I have been wondering what the correct solution
is for the problem of calling LAPACK routines when we have 64-bit
ints.  I think the current patches assume that any Fortran code has
been compiled such that all INTEGER data is 8 bytes.

| - IEEE 794 (floating-point) support

Yes, I think it would be best if LAPACK (and BLAS) supported
operations on Inf and NaN "correctly" by default.

Also, I think that people will expect performance like ATLAS.  OTOH,
maybe you are only thinking about the interface and a reference
implementation and would still leave optimization up to other
projects?  In that case, then I would hope to see ATLAS adapted to use
the new algorithms and interface defined by the new LAPACK.

Finally, here are some other minor things that I can think of

  * A way to ask the library about capabilities or to get version
    information.  When LAPACK changed to allow (some of?) the routines
    to be queried for workspace requirements, there was no easy way to
    ask whether a vendor-supplied version of the library supported the
    new feature.

  * A more modern way to build the library (perhaps using
    automake/autoconf/libtool?)

  * A public mailing list for bug reports.

  * Releases clearly tagged with version numbers and dates.

Thanks,

jwe