|
|
Ublas : |
Subject: Re: [ublas] [bindings] Lapack generator update
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2008-12-16 12:57:24
Rutger ter Borg wrote:
> Please find attached two files generated with the latest bindings generator.
> These are examples for gelsd and heevx.
I took a look at them. These are indeed good examples to see where the automatically generated bindings stand with respect to the existing bindings.
> I know it is not perfect yet, it doesn't compile,
I don't care that it doesn't compile, but "heevx_base_impl" is not even used. How is it supposed to be used? Is there any problem with the inline function overloads?
> but it has made some significant progress into the next abstraction level.
I see. Instead of
namespace detail {
template <int N>
struct Heevx{};
...
}
we have
template< typename ValueType, typename Enable = void >
struct heevx_impl{};
Since we always know our value type, we only need to write
heevx_impl<value_type>()(...)
and the correct thing can be done.
For example syevx<traits::complex_f> can generate a compile error (or dispatch against a complex symmetric eigenvalue solver when lapack adds one), while heevx_impl<double> can dispatch against dsyevx.
And the idea is probably to also have
template< typename MatrixType, typename Enable = void >
struct eigen_impl{};
that can do the correct dispatch based on matrix type.
> I thought a message around this topic would draw your interest :-).
I thought you might be want to get some feedback :)
> I have to come to the conclusion that we need to introduce
> a type (=struct/class) for each lapack subroutine.
There are many ways to read this statement. Do you mean we need to introduce a different type for CHEEVX and ZHEEVX? Or do you just mean something along the lines of "template <int N> struct Heevx{};", as some bindings currenty use? Or do you refer to something like "template< typename MatrixType, typename Enable = void > struct eigen{};"?
> I see that in some of the bindings
> the class-structure already is in use to dispatch to
> different value_types (usually no. workspaces at the moment).
So I guess you refer to "template <int N> struct Heevx{};", or more specifically to the improved version "template< typename ValueType, typename Enable = void > struct heevx_impl{};". Two things come to my mind:
1) It's probably a good moment to say goodbye to BOOST_NUMERIC_BINDINGS_POOR_MANS_TRAITS, or at least to VC-6.0 support for the lapack bindings. I don't know where VC-7.0 and VC-7.1 stand in this respect.
2) The bindings currently fully support custom types, i.e. complex_f can be anything (i.e. it's not valid to assume it's complex< float >), as long as it has the correct memory layout for the lapack routines. This only means that the user has to take care that is_real, is_complex, ... is correctly specified for his type. Whether his type is complex enough for other algorithms is his own problem.
So i think that's the correct way to go forward, but we have to take care that we don't impose the restriction that complex_f must be equal to complex< float >.
Regards,
Thomas