OONumerics User : |
From: Michael Lehn (michael.lehn_at_[hidden])
Date: 2007-06-25 15:21:40
Hi Toon,
maybe the more interesting question would be: Why doesn't FLENS use
the Boost bindings as building block?
So far I just wanted to keep the dependancies on external libraries
low. And for my personal proof of concept a "quick and dirty"
implementation of my own BLAS and LAPACK bindings was sufficient.
But it should be just a matter of some manual labor to replace the
FLENS bindings for BLAS and LAPACK with the bindings form the boost-
sandbox. As far as I can see it should only require to define some
traits.
My motivation for FLENS comes from a different direction: I wanted a
C++ library that allows me to implement reusable numerical
algorithms. Satisfying some constraints:
1) The library should allow me to use an expressive notation, i.e. as
close to the pseudo-code as possible.
2) It should be possible that actual computations get done by
external libraries. For instance BLAS and LAPACK. I think this is a
"necessary condition" for a numerical library to compete in these
field (but it should not be restricted to just these two libraries).
Actually many algorithms in numerical analysis are developed having
in mind what and how many BLAS function are required.
3) The library should allow correct allocation of matrix and vector
types as used by BLAS and LAPACK: e.g. storage schemes for general,
banded and packed matrices. These should not be actual matrix types
as they are no matrix types in the sense of BLAS either. E.g. a
banded storage scheme can be used for a general, symmetric,
triangular or hermitian matrix. However these schemes can serve as
implementations for actual matrix types (like FullStorage,
FullStorageView, ConstFullStorage in FLENS for GeMatrix, SyMatrix,
TrMatrix).
4) The library should have a nice notation, but at the same time no
runtime overhead compared to directly using BLAS. There should be a
one-to-one corresponding between expressions using overloaded
operators and directly calling BLAS. For example
y=2*A*x+z
should be equivalent to calling
gemv (or gbmv, symv, ... this should statically depend on the matrix
type)
and
axpy.
There should be no side effects. If you need temporaries these
should never get created implicitly, e.g.
i) A=B*C*D can not be computed using BLAS without a temporary.
So this should fail. Otherwise it would support inefficient coding.
ii) x=A*x, if A is triangular this is fine. Otherwise this
should fail (FLENS will only check this in DEBUG mode). In my
opinion this is a good thing. In numerical algorithms you precisely
know whether you want y=A*x followed by y=x or whether you really can
do it with x=A*x. At least you have to think about that if you use
BLAS directly. Hence, by definition you have to do the same thinking
if you just use a different notation.
5) It should be possible and easy to define your own vector and
matrix types. In particular it should be easy to integrate these
user-defined types into the rest of the library. What this means in
my understanding I tried to illustrate on
http://flens.sourceforge.net/session3/tut3.html
It shows a very special and very simple matrix type. If you want to
use this type for the conjugated gradient method all you have to
implement is your own matrix-vector product. FLENS intends that in
such cases ideally you have to implement (maybe in Fortran or
assembler if one likes) just one function. It only requires that the
signature of this function conforms to corresponding BLAS functions.
In other cases you have things like "it's mathematically a vector,
but for the implementation it's better a matrix" like "GridVector2D" in
http://flens.sourceforge.net/session3/tut4.html
6) Implementation of user-defined matrix/vector types also could be
used to allow other policies of evaluation. Like A=B*C*D with
implicit temporaries. Or x=A*x for non triangular matrices with a
implicit temporary vector if necessary. But as I said, I personally
have no need or interest for that. More interesting are additional
matrix types like TinyMatrix where operations are evaluated using
expression templates. In combination with BLAS this could be
extremely useful.
7) It should be possible to implement simple things simple.
Finally I have to admit that I only implemented very few bindings for
BLAS and LAPACK. Just to see if this concept works.
I hope I could express myself reasonably clear,
Michael
Am 25.06.2007 um 17:35 schrieb Toon Knapen:
> Interesting. Do you also know about the BLAS and LAPACK (ans slatec
> and ...) bindings in the boost-sandbox ? How do you compare these
> with FLENS?
>
> Thanks in advance,
>
> Toon
>
> Michael Lehn wrote:
>> Hi everybody,
>> there is a new release of my numerical library FLENS:
>> http://flens.sf.net/
>> Here a short description of FLENS:
>> FLENS (Flexible Library for Efficient Numerical Solutions) is a C+
>> + library for scientific computing. It can be considered as a
>> very convenient and extremely efficient interface for BLAS and
>> LAPACK, but it is also much more than that.
>> What I mean with "... more than that" might become more clear if
>> you have a quick look onto my (uncomplete) FLENS tutorial:
>> http://flens.sourceforge.net/tutorial.html
>> Cheers,
>> Michael
>> _______________________________________________
>> oon-list mailing list
>> oon-list_at_[hidden]
>> http://www.oonumerics.org/mailman/listinfo.cgi/oon-list
>