Boost logo

Ublas :

Subject: Re: [ublas] [bindings] Initial submission plan?
From: Rutger ter Borg (rutger_at_[hidden])
Date: 2009-02-10 16:19:37


Thomas Klimpel wrote:

> 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.

I have been following the development of the numeric bindings since 2002...
Evolution has had its chance :-). But seriously, it's a good library and I
think it deserves more attention than just a sandbox. Writing the bindings
generator has been possible due to the hard work of the authors of the
current bindings. I don't think it's that revolutionary.

> 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:
>
> [snip]

Good plan, we need clearly stated overview of supported environments. Let's
start by stating this in the documentation. Perhaps also start with
ticketing in trac.

> 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.

The generator script doesn't support BLAS generation just yet, ATLAS needs
to be merged, etc., etc.. There's still a lot to do, but as I see it,
coding the library itself doesn't seem to be the most time-consuming part
anymore. We need help with setting up a full testing suite (based on
current), testing on different environments/compilers, and with writing
documentation.

> 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?

I heard about CUDA recently. Apparently nVidia ships a BLAS that runs on
GPUs, tenfolds faster compared to CPUs. Not that expensive as well.
http://www.nvidia.com/object/cuda_learn.html

> 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.

I think the scope of the Numeric_Bindings is just that: having C++ access to
non-C++ numeric libraries with a high-level interface without paying for it
in run-time costs. FFT served as an example; it certainly is one that has
very efficient non-C++ implementations (e.g., FFTW). To further motivate,
fourier transforms are also included by Intel's MKL, AMD's CML, and
nVidia's CUDA.

> But the initial question was for clear goals.

Yes.

> Since I have the impression that you will do the main work,

Please don't :-)

> 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.

I think it should support the whole of BLAS, and of LAPACK, and back-ends
such as ATLAS supported where possible. Seperated high-level and low-level
interface(s) don't seem to be too far off anymore, but needs some more
research.

> 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).

I agree, I see a lot of use for being able to write

lapack::qr( ... );

If time permits, I'll try to create the structure in the sandbox tomorrow,
let's start expanding the documentation with stuff we just discussed. All
help is greatly appreciated.

Thanks,

Rutger