Re: [eigen] matrix function / exponential warnings

[ Thread Index | Date Index | More Archives ]

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.


> - Hauke

Mail converted by MHonArc 2.6.19+