Re: [eigen] new tutorial on writing functions taking Eigen types as paramters

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

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

Note that you have to put the template keywords:

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.

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