|
|
Ublas : |
Subject: Re: [ublas] [bindings] Initial submission plan?
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2009-02-10 14:12:32
Rutger ter Borg wrote:
> with the progress on the bindings as they are at the moment, I was
wondering
> whether it would make sense to set clear goals, so we can work towards
a
> point where we could submit the library for comments and after that
for
> review.
I can understand that...
However, I had hoped to have some sort of "real" release (with
statements about what is supported and what isn't) before submitting the
library for review. And I had more hoped for some sort of evolution
instead of a revolution.
> To start the discussion, I think it should contain the BLAS, LAPACK,
and
> Traits parts. This doesn't exclude the ATLAS bindings, because as I
see it,
> ATLAS is a type of back-end, and as such, its support should be
integrated
> in the BLAS and LAPACK parts.
Interesting point. I came from the other side, i.e. I took the existence
of the numeric_bindings library for granted, but asked how it should
evolve. I'll explain what I mean:
- Support for VC-6.x and VC-7.0 is difficult and I don't have access to
a corresponding compiler. Hence I would like to drop it.
- The AMOS bindings are very incomplete and buggy. I haven't seen
anybody using them. I would also like to drop them.
- Support for 64-bit systems will become ever more important. I should
try to ensure that it works on these systems.
- Users will mostly have windows, linux and mac systems. I should try to
ensure that it works on these systems.
- Users will try to use amd's ACML and intel's MKL, so I should try to
ensure that it works with these libraries
- ATLAS offers reasonable support for row-major and the bindings are
more complete than the BLAS bindings. I should try to ensure that ATLAS
keeps working, and trying to bring BLAS bindings to a similar level of
functionality than the ATLAS bindings.
- Umfpack and MUMPS have somewhat restrictive licenses, but so has GSL.
The support for them in the numeric_bindings seems to work fine, and
umfpack seems to be used by many users. The reason that MUMPS is used
less often probably relates to the fact that you have to register before
somebody sends you a download link. I see no reasons to drop support for
Umfpack and MUMPS. I even see reasons to keep them, because LAPACK and
BLAS don't make use of the sparse_matrix traits.
- ...
But I think it is clear what you want. In order to be able to submit the
library for review, one has to try to limit its scope somehow. And you
want to start a "clean" workspace under sandbox/numeric_bindings and
want to avoid adding "dead" parts to it.
> Like some other boost libraries, other bindings could be added after
the
> initial release, e.g.,
I had hoped to have the "initial" release not as part of boost, but to
get included into boost later. The inclusion into boost would have been
some sort of "long time vision". Even the "lapack generator" script was
more meant like some sort of vision to keep the motivation alive than
anything I really expected to finish in the near future. But since you
obviously finished it already, chances are that you will also bring the
entire library into a state that it can be submitted for review.
> * Boost.Numeric_Bindings: C++ numeric type traits, bindings for BLAS,
> LAPACK. Support for ATLAS, nVidia CUDA?, etc.
The support for ATLAS is somehow quite closely related to the bindings
for BLAS and LAPACK, since it is a subset of the functionality, but with
support for row-major. What do you mean by support for nVidia CUDA?
> * Boost.Numeric_Bindings/FTT: support for fast fourier transforms
through
> back-end1, back-end2, etc.
I don't see FFT bindings in the scope of the numeric_bindings library. I
guess this is because I see mostly the "linear algebra"/"matrix" aspect
of the numeric_bindings, and the FFT is not really related to the
"matrix" aspect.
> What do you think?
But the initial question was for clear goals. Since I have the
impression that you will do the main work, I think it is great when you
will succeed to have high quality BLAS and LAPACK bindings in a form
ready to submit it for comments and later submit it for review. So when
you create your "clean" workspace under sandbox/numeric_bindings, feel
free to only add those things that you want to have in your first
version.
>From a functionality point of view, I think that the first version
should try to support at least the subset of BLAS/LAPACK functionality
supported by ATLAS + the functionality of the simple and expert lapack
driver routines.
>From the computational lapack routines, the routines required for
multiplicative decompositions like LU and QR decomposition and the
corresponding back substitutions also seem important. Also routines for
bidiagonal, tridiagonal and Hessenberg matrices might be important as
these might be required as building blocks in certain algorithms (for
example Lanczos algorithm for eigenvalue approximations).
Regards,
Thomas