Re: [ublas] [bindings] matrix traits

Subject: Re: [ublas] [bindings] matrix traits
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2008-12-19 07:56:45

Hi Rutger,

Rutger ter Borg wrote:
> I was actually looking for what additional traits might be included into the
> auto-generated bindings. I've added uplo (see, e.g., heevx attached). In
> case of gels (see other attachment), it has the option to work on a
> transposed matrix A. I think because of what you're saying that we could
> choose for something like 
> 
> lapack::solve( A, ... )
> lapack::solve( trans( A ), ... )
>
> and keep the trans argument in gels, and pass the right parameter to it. In
> other words, 'trans' is not determined by traits in gels itself, but
> outside of gels.

I think the "trans" you describe here falls into the category of "type-refinement" I described earlier:

Thomas Klimpel wrote:
> > lapack::eigen( A, left_eigen_values( vl ) );
> > lapack::eigen( A, right_eigen_values( vl ) );
> > lapack::eigen( A, right_eigen_values( vr ), left_eigen_values( vl ),
> > eigen_vectors( W ) ); 
> The decorations are a nice idea, since they allow to state the role of certain arguments.
>
> > lapack::eigen( symmetric_lower( A ), left_eigen_values( vl ) );
> > lapack::eigen( hermitian_upper( A ), right_eigen( v ) );
>
> symmetric_lower and hermitian_upper fall into a different category.
> These are some sort of type-refinement. I thought about these before
> in the context of interpreting a vector as a matrix, because a vector
> might be interpreted as a (1,n) or as a (n,1) matrix, and this sort
> of type-refinement allows to distinguish the two cases. 

A "type-refinement" is therefore some sort of adapter (provided by the numeric-bindings library) that can be used with any type that has the corresponding traits. Such adapters could help avoid excessive requirements on the underlying types and yet allow a nice user interface for the numeric-bindings library.

> As a sidenote, is it correct that with the current bindings,
> user-defined workspaces are not asserted for their minimal sizes?

No, they are. I guess you looked at gels again, but the gels bindings are not a good example of how the bindings are supposed to work (as I explained earlier, by the way I have now finished the 64-bit port). If you look at heevx.hpp or any related binding, you will see that they assert user-defined workspaces for their minimal sizes.

> I would like to include these asserts, that's why would like to introduce
> separate functions for the minimal sizes of all work arrays.

I see, your specialization of the gels_impl template with respect to ValueType now really comes in handy (because the different "min_size_work" would interfere with each other otherwise). So I think it is a good idea to implement these in the way you have done.

On the other hand, I would still prefer to have the overloads for the fortran function calls as inline function overloads in a "detail" namespace outside of the gels_impl template. This would be more consistent with the blas bindings, and would generally highlight that this is something needed for any bindings against fortran libraries, not just lapack. One could also note that this is essentially the "non-portable" part of the bindings. Have a look at the "select" argument of the GEES binding to get a feeling for what I mean with this statement.

Regards,
Thomas