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*: Tue, 17 Aug 2010 09:26:43 -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; bh=PAbPJxQLbl8Dg+WyvXV2wIfeF5IxC5RYvDuaXurKhAU=; b=Y9S9x/KLgSynkz4iKLAc+o9PVqH95Q6hZ0NQAKadcDz9h9+9jZ/8xbfgjQl2TIBFQ7 OlRr1XiJJ0jDVa6RWH7fBZt1Z4cRU5bi6qlg1VpC+S/ZsfrX56mCaSiEydgFa6LhF2bZ cb+Q5bl+4zVBUkjE2L1Qa3Cgh4eTTR71lfE+A=*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; b=pmxBeUjr8tKzf+yXPXN+71F92iRtMlvZJMWJfdhiSpc9mXkIyV4C4ip19dRNzPaTvD 3ROjXvSVuu1ywwET0jjCKLs9f4FLPErHUIkHMJjbGDDEtzFXDef+MmBCYz31TpRGGMms E2Khhng6VYMfZbBvf/pIELPzCerJTFmlsnToA=

2010/8/17 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>

I'm OK with this proposal, although the name NestedForMultipleAccess had the advantage of making it clear what the number was meaning.

Note that since the only values that will ever be used are 1,2,Dynamic, we could also make typedefs for them, so that in 99.9% of cases one wouldn't need the template keyword.

Benoit

Note that you have to put the template keywords:On Mon, Aug 16, 2010 at 3:50 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:

> 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);

typename XprType::template NestedForMultipleAccess<2>::Type myvar(myarg);

Actually, I would have preferred something more consistent between the

case with N=1 and the multiple access case. So what about redefining

Nested to what you suggested with N=1 for the default value:

typename XprType::template Nested<>::Type myvar(myarg);

typename XprType::template Nested<1>::Type myvar(myarg);

typename XprType::template Nested<2>::Type myvar(myarg);

typename XprType::template Nested<Dynamic>::Type myvar(myarg);

and for brevity we could add a NestedType shorcut which is

syntactically consistent:

typename XprType::template Nested<>::Type myvar(myarg);

typename XprType::NestedType myvar(myarg);

it's just an attempt to make things a bit more consistent, your

proposal might be fine too.

I'm OK with this proposal, although the name NestedForMultipleAccess had the advantage of making it clear what the number was meaning.

Note that since the only values that will ever be used are 1,2,Dynamic, we could also make typedefs for them, so that in 99.9% of cases one wouldn't need the template keyword.

Benoit

gael

> 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

>>>

>>>

>>>

>>

>>

>>

>

>

>

**Follow-Ups**:**Re: [eigen] new tutorial on writing functions taking Eigen types as paramters***From:*Gael Guennebaud

**References**:**[eigen] new tutorial on writing functions taking Eigen types as paramters***From:*Hauke Heibel

**Re: [eigen] new tutorial on writing functions taking Eigen types as paramters***From:*Benoit Jacob

**Re: [eigen] new tutorial on writing functions taking Eigen types as paramters***From:*Hauke Heibel

**Re: [eigen] new tutorial on writing functions taking Eigen types as paramters***From:*Benoit Jacob

**Re: [eigen] new tutorial on writing functions taking Eigen types as paramters***From:*Hauke Heibel

**Re: [eigen] new tutorial on writing functions taking Eigen types as paramters***From:*Benoit Jacob

**Re: [eigen] new tutorial on writing functions taking Eigen types as paramters***From:*Gael Guennebaud

**Re: [eigen] new tutorial on writing functions taking Eigen types as paramters***From:*Hauke Heibel

**Re: [eigen] new tutorial on writing functions taking Eigen types as paramters***From:*Gael Guennebaud

**Re: [eigen] new tutorial on writing functions taking Eigen types as paramters***From:*Benoit Jacob

**Re: [eigen] new tutorial on writing functions taking Eigen types as paramters***From:*Gael Guennebaud

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Optimization for special complex operations** - Next by Date:
**[eigen] Getting to a solution from sparse matrices, Eigen3** - Previous by thread:
**Re: [eigen] new tutorial on writing functions taking Eigen types as paramters** - Next by thread:
**Re: [eigen] new tutorial on writing functions taking Eigen types as paramters**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |