Re: [eigen] nesting

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

To summarize the little conversation that happened over irc:

1) Hauke: a very good reason why we want to evaluate intermediate
temporaries also in the fixed-size case, as mentioned by Gael, is when
the cost-model tells us that this reduces the complexity of the
operation. For example, evaluating b+c in "a*(b+c)".

2) On the other hand the idea of an "expression evaluator" seems
really doable (albeit complex) following this strategy:

a) At the time of the construction of the expression, we gather the
information of where temporaries must be introduced when evaluating
that expression. That could be a new typedef in ei_traits.

b) when evaluating an expression, we instantiate an object of a
template "Evaluator" type that uses that information to hold the
necessary temporary matrices as member data. We then traverse the
expression tree, evaluating the designated sub-expressions into these
temporaries.

I'm not saying that I'm finding this _easy_!! This has got to be the
most complicated templates exercise that we've had to solve. But it
can be done for sure, as templates allow to do everything. To think
about that, I'm finding it convenient to think purely in terms of
pseudo code, and translate this into templates at the last minute.
Templates are not human-readable code :(

Benoit

2010/2/7 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>:
> On Sun, Feb 7, 2010 at 4:51 PM, Gael Guennebaud
> <gael.guennebaud@xxxxxxxxx> wrote:
>>> Currently, I am also a little bit confused about the following code
>>> (from the forum):
>>>
>>>  double p = (P.transpose * P).diagonal().sum();
>>
>> in the devel branch Product::diagonal is overloaded to handle that case
>> without the need of an explicit lazy.
>
> Though it is crashing over here. I have to investigate but I think it
> is the same reason as before, a deleted temporary.
>
>
>