|
|
Ublas : |
From: Karl Meerbergen (Karl.Meerbergen_at_[hidden])
Date: 2008-08-18 07:32:12
Thomas Klimpel wrote:
>> One possibility that should please everyone is to have both names,
>>
> but
>
>> in the complex case the symmetric function name might not exist (since
>>
>
>
>> it mathematically does not make sense) or mean someting else than its
>> Hermitian brother.
>>
>
> I agree.
>
> However, I don't know how to completely eliminate the symmetric function
> name in the complex case, so I use BOOST_STATIC_ASSERT to forbid its
> use:
>
> #ifndef BOOST_NUMERIC_BINDINGS_NO_STRUCTURE_CHECK
> typedef typename A::value_type
> value_type ;
> typedef typename traits::type_traits< value_type >::real_type
> real_type ;
> BOOST_STATIC_ASSERT((boost::is_same<value_type,
> real_type>::value));
> #endif
>
Hm. I suppose it is sufficient the corresponding lapack overloads do not
exist. For example,
the syev() overload for each value_type, using LAPACK_SSYEV and LAPACK_DSYEV
does not exist in the complex case, whereas heev() uses LAPACK_SSYEV,
LAPACK_DSYEV, LAPACK_CHEEV and LAPACK_ZHEEV.
But this might generate compiler errors that are not very clear to a
non-expert user. Checking the value_type looks cleaner indeed. For
LAPACK, it is possible to do a check like:
BOOST_STATIC_ASSERT(( boost::mpl::or_< boost::is_same< value_type, double >, boost::is_same<value_type,float> >::value));
Explicitly listing the valid value_type's looks ok to me, since LAPACK
is a library that only supports 4 value_type's.
Karl
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
>