|
|
Ublas : |
Subject: Re: [ublas] [bindings] Lapack generator update
From: Rutger ter Borg (rutger_at_[hidden])
Date: 2008-12-16 13:35:12
Thomas Klimpel wrote:
> 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?
I was thinking of deriving heevx_impl from heevx_base_impl. If we do that,
everything is uniformly accessible through any member function we choose,
say, operator(). I.e., in this case, we have a uniform interface to both
abstraction levels:
heevx_impl<value_type>::operator()( ... short call with templates ... );
heevx_impl<value_type>::operator()( ... lengthy direct lapack call ... );
It's not giving us a lot of benefit, but, well, could be nice to have. But,
this can also be accomplished without deriving and putting these member
functions directly in heevx_impl. I was still pondering on that.
> Since we always know our value type, we only need to write
> heevx_impl<value_type>()(...)
> and the correct thing can be done.
Yes, and because the member functions are static, you may even call them
without instantiating the struct:
heevx_impl<value_type>::operator()(...)
this is important, because it is needed for compile-time accessibility, and
we will be dealing with more compile-time stuff soon. I think it is also
more efficient.
> 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.
This could be an option, however, I would recommend keeping the generated
bindings to do their thing, and making the compile-time selection you
mention one step in earlier in the chain: at the user-callable functions.
> 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.
It is the idea, albeit a bit different. I guess enable_if will be
insufficient for our needs in this case - the specialisations needed will
probably be based on more than just the matrix_type, things like the number
of arguments and types of arguments come to mind. This will probably end up
being MPL magic :-). I'll try to produce an example soon.
> I thought you might be want to get some feedback :)
Yes, thanks :-).
> 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{};"?
Indeed, the second option, I mean a struct/class per group of lapack
functions, i.e., a struct for heevx, gelsd, etc.
> 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.
Do you know what/where it was needed for?
> 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.
Cool, didn't know that. Is this a feature and/or really needed? If not, we
could suffice with
std::tr1::is_complex< T >
std::tr1::is_floating_point< T >
because, after all, we are creating C++ bindings... On the other hand, it's
not a big deal to create our own.
Cheers,
Rutger