Re: [eigen] matrix function / exponential warnings

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

2010/6/20 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>:
> On Sun, Jun 20, 2010 at 5:16 PM, Jitse Niesen <jitse@xxxxxxxxxxxxxxxxx> wrote:
>> What warnings do you get? I don't remember that I got any, so I guess it's
>> MS specific. I think that MatrixBase::fullPivLu() does something very
>> similar, so I'm interested why you don't get warnings there.
>
> I got this one:
>  warning C4181: qualifier applied to reference type; ignored
>
> It is happening when you do e.g. something like this:
>  typedef int& IntRef;
>  int a = 5;
>  const IntRef b = a;
>
> So nothing to worry about though I really want to have a green
> dashboard for 3.0.

The fix here is to replace const IntRef  by typename ei_makeconst<IntRef>::type

....yes, this is a constifying metaprogram :)

>
>> I thought that eval() always returns either a PlainObject or a constant
>> reference to a PlainObject. That's what the comment "ei_plain_matrix_type:
>> the difference from ei_eval is that ei_plain_matrix_type is always a plain
>> matrix type,whereas ei_eval is a const reference in the case of a matrix" in
>> XprHelper.h suggests to me.
>
> ei_eval<T> is either a
>
>  PlainObject = ei_eval<T>::type
>
> or it is a
>
>  T const&
>
> or even a
>
>  T
>
> So in case you really want to store your temporary, I would just do
> this (which I did in my patch)
>
> const typename Derived::PlainObject srcEvaluated = m_src.eval();

i haven't looked at the specifics. It depends on this question: if src
is already a plain matrix, do you want to copy it, or do you want to
avoid copying it?

>
>>> Any comments? Is there a particular reason why ei_nested<...>::type
>>> should not be working out of the box?
>>
>> I don't know what n should be in ei_nested<...> . It should definitely be
>> high because computing matrix functions is very expensive. In fact, I
>> thought that the argument of matrix functions should always be evaluated in
>> situations like (matrixA+matrixB).exp() onless the argument is a matrix as
>> in matrixA.exp(), in which case there is nothing to evaluate. This is
>> exactly what eval() is doing.
>
> Yes, you may be totally right. I think it does not make much sense to
> go any further. Even though I added right now ei_nested, it should
> change pretty much nothing because ei_nested<PlainObject> is in fact
> "PlainObject const&".

For the record, the n in ei_nested is (a rought estimate of) the
number of src coeff accesses per coeff access in the present
expression. This is explained in a big comment next to the source code
of ei_nested in XprHelper.h. In practice, as soon as n is >=2, this is
almost always equivalent to ei_eval, but that is not a definition,
this is the result of the current heuristic that we're using, which is
the result of our experiments to see what's fastest.

Benoit

>
> - Hauke
>
>
>