Re: [eigen] Returning an expression unifying two types of matrices

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

I see two options:

1 - you replace getG by getG_diag and getG_full, and anytime you have
to use G, you do something like:

if(obj.gIsDiag())
  bla * obj.getG_diag() * blabla;
else
  bla * obj.getG_full() * blabla;

2 - you add a template <typename Rhs> multByG(const Rhs& rhs) const {
return ...; } function that will return a temporary. Since G is always
squared, the returned type (a Matrix<> object, not an expression) will
always be the same. You might need two versions to multiply on the
right or on the left. You might also write a very small wrapper
storing a ref to obj with custom operators* that will do the dynamic
branching:

 bla * obj.getG() * blabla;

obj.getG() will return a wrapper object, bla * obj.getG() will be
evaluated by your custom operator* that will do the branching and
return a Matrix<> object.

gael

On Thu, Nov 24, 2011 at 9:06 PM, Jens Mueller <jens.k.mueller@xxxxxx> wrote:
> Rhys Ulerich wrote:
>> On Nov 24, 2011 8:19 AM, "Jens Mueller" <jens.k.mueller@xxxxxx> wrote:
>> >
>> > Hi,
>> >
>> > I'm facing a problem and don't know how to approach it.
>> > In my code I have many expressions of the form y.transpose() * getG() *
>> > y, where y is a column vector of length n and getG() returns a reference
>> > to a nxn matrix.
>> > Sometimes I know that G is diagonal (at run-time) and I'd like to use
>> > this information when evaluating the expressions (storing a diagonal is
>> > also much cheaper).
>> > I need to store G somewhere to return it. But G is either a full matrix
>> > or a diagonal matrix. So what do I store?
>>
>> Store neither. Pass vector y into a method that, like getG, knows how to
>> compute either inner product expression (using G diagonal or full
>> efficiently)*.* Return the scalar result.
>
> Currently, the matrix is stored in a class A and another class B uses
> class A for its computations. Moving the computation to A breaks this
> separation. And the expressions using the matrix may become more diverse
> in future. So I should add that there are different expressions (all
> similar to the one above) but may have more terms. And all need to
> access the matrix G.
> Maybe my current design is just broken.
>
> Jens
>
>
>