Re: [eigen] new tutorial on writing functions taking Eigen types as paramters |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] new tutorial on writing functions taking Eigen types as paramters
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Mon, 16 Aug 2010 09:50:59 -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=rYokE1uIBrPOircYcmid2vORUj1DKebzZBJ089JP8cw=; b=e7Jshrz7IyeXRTBRfOT9tdrYQ/KE147kgYTqRW7CW0nafk7E8+oSIQOTgMje2/D4hg 0EeBX7TPxUt47ldzmVfpZoChP0BKMV1B4QgfPup1Spue9eKt2KoN6A2uSB+Hn3rOHcut NKhkQWfm2UzKSEjAozEDQHqMX1wgaXQuFr/V4=
- 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=YRLG+r6RtW+C/euDDV9reIPgaGT1InKRq0PRzX2B6fN7qZAi2MTpSN2HCTF9tjVNfC DoaV4qkNYjlDDvzORiEZ6o8Q+msaFU+u8srAj2bxu/UnLu9DdrMj+vXwGyAWbQa1smHH soC14VVlvwrYvgnbPAeMhbzXrIfgTuFPf+svk=
2010/8/16 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> On Mon, Aug 16, 2010 at 12:13 PM, Hauke Heibel
> <hauke.heibel@xxxxxxxxxxxxxx> wrote:
>> On Mon, Aug 16, 2010 at 11:55 AM, Gael Guennebaud
>> <gael.guennebaud@xxxxxxxxx> wrote:
>>> On Thu, Aug 5, 2010 at 3:48 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>>>> - mention Nested (at the end of the page! it's an advanced topic, but
>>>> it's important for advanced users).
>>>
>>> I don't think this is an advanced topic, and to be safe, every
>>> argument should be systematically converted to their nested type:
>>
>>> template<typename Derived> void foo(const MatrixBase<Derived>& _x)
>>> {
>>> typename Derived::Nested x (_x);
>>> // use x, not _x
>>> }
>>
>> Do we need this as a safeguard for types that require evaluation
>> before nesting? Here it would be more like "require evaluation before
>> further usage".
>>
>> But is it really true, that we need something like this? Could you
>> maybe help me out with a use case? When somebody were passing a
>> product, that would anyways use it's internal temporary, right?
>
> yes, for instance for products, or the objects returned by the solve
> functions. Here is an example:
>
> template<typename Derived> void foo(const MatrixBase<Derived>& x)
> {
> if(x(0,0) >0) ...
> }
>
> This code will work most of the time but not always.
>
> Another issue is when the argument is used multiple time and it is en
> expensive operation... In this case the function writer has to use the
> internal ei_nested<> helper class... My opinion is that we should come
> up with a simple mechanism/rule to declare and use arguments, and
> encourage user to always use it, e.g.:
>
> EIGEN_ARG(DerivedA, _a, a, 2);
> EIGEN_ARG(DerivedB, _b, b, 1);
> EIGEN_ARG(<type>, argument_name, variable_name,
> number_of_time_each_coeff_of_the_argument_is_read);
>
> ^^ this is just a poor proposal to get the idea.
>
> The alternative would be to "fix" Eigen itself, but I don't know how to do so...
If the only thing that the user ever had to use was Nested, do we
agree that we would let them do:
typename XprType::Nested myvar(myarg);
as this is barely longer than using such a Macro, and makes it more
clear what is happening?
If we agree on that, then the only problem we have to solve is that
sometimes the user wants something different than what Nested does.
How about introducing a new "templated typedef" in all our
expressions (just a 1-line change because we are using macros
internally to generate these typedefs anyway):
template<int N> struct NestedForMultipleAccess {
typedef typename ei_nested<Derived, N> Type;
};
so the user could do, in his function:
typename XprType::NestedForMultipleAccess<2>::Type myvar(myarg);
or
typename XprType::NestedForMultipleAccess<Dynamic>::Type myvar(myarg);
Cheers,
Benoit
>
>>
>>> For advanced user we should also explain ei_nested which is preferred
>>> if the argument is used more than once. Since ei_nested is mostly
>>> internal, maybe we should also add a slightly higher level public
>>> wrapper....
>>
>> Should not ei_nested<Derived> in theory be the same as Derived::Nested?
>
> Yes, they are the same, but ei_nested is more powerful since it allows
> you to tell how many time the object is being used, and more...
>
>
>
> gael
>
>
>
>>
>> - Hauke
>>
>>
>>
>
>
>