|Re: [eigen] matrix function / exponential warnings|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] matrix function / exponential warnings
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Sun, 20 Jun 2010 12:20:38 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=lA7o6zMnkJVo07eRlMnUcY1mCjja0lLrMwfyxJUnv6w=; b=op2rLQtOSuhxdULIDzNf7mYKpQKh8+HpmsOTrnJzrDXcvdLHtT2+TTLiG82eo+z/yu UpWzO+8Tw/KzUr6XUs+SUGInjR4lZOxWQmsp4prsf5byYSx6FBYAmgMBKUt9h0XMd37/ tRxep6UgooGS67IzR69jaeRQ8N1e1wH0x4niY=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=P52F31yXiqkEVpyjznhtwVG3/GUfhylXeWu1nQ0x89GT8Ew6VQYcywQMgt6lU0JQkQ TTNarOnVs04tVbMn155wY4QPynI+qQhxWrB/3lVfcVUJDB1/7dSd7MQidBUp3kOt9UfG J0hNv44ONtf6ymN37GzVssGIqg6LPNryjZtP4=
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
> 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