Re: [eigen] Clang issue on MacOS when the set variable is used in the gi

Thanks Gael for these hints, I will rewrite the code in consequence.

Regarding this point
> Is this case it amounts to the same because you multiply it to an
> object that has compile time sizes, but it general it's better to
> specify the sizes at compile time when you can.

and
> In general, the more specific, the better. So segment will never be a
> worse choice.

So it means that:

- operator<< (): is a very general tool and can handle everything (but be carefull to not read the matrix you are filling)

- block()/segment(): similar to operator but is not affected by the reading/filling effect

- segment<>, tail<>, block<> : only specific for operation with known compile time dimensions but have the best perfornance.

Sorry for all of these (noob) questions. I think I didn't get it right long time ago :-)

On Fri, Apr 19, 2013 at 2:06 PM, Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:

On Fri, Apr 19, 2013 at 2:02 PM, Arnaud BARRE <arnaud.barre@xxxxxxxxx> wrote:
>>With Eigen's _expression_ template this makes it a little bit more subtle.
>> For instance:
>>A << ...., A.block(...) + B, ....;
>> ...
>
> So, as a best practice rule, is it better to use comma initialization only
> with constant values?

no, I would only recommend not to read the matrix/vector your are filling.

> And in other case, like mine, It is better to use the segment() or block()
> method? I never knew wich one is the best (in term of code instruction).

In general, the more specific, the better. So segment will never be a
worse choice.

gael

> Arnaud
>
>
>
> On Fri, Apr 19, 2013 at 1:46 PM, Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
> wrote:
>>
>> OK thank you for the finding. I'll add this note in the doc.
>>
>> With Eigen's _expression_ template this makes it a little bit more
>> subtle. For instance:
>>
>> A << ...., A.block(...) + B, ....;
>>
>> as a well defined behavior, this is the first "...." will be entirely
>> executed before A.block(...) + B gets evaluated, but:
>>
>> A << ...., (A.block(...) + B).eval(), ....;
>>
>> does not!
>>
>>
>> gael
>>
>> On Fri, Apr 19, 2013 at 1:33 PM, Christoph Hertzberg
>> <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>> > On 19.04.2013 13:23, Christoph Hertzberg wrote:
>> >>
>> >> On 19.04.2013 13:14, Gael Guennebaud wrote:
>> >>>
>> >>> On Fri, Apr 19, 2013 at 12:53 PM, Christoph Hertzberg
>> >>> <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>> >>>>
>> >>>> I always assumed that
>> >>>> foo << A, B, C;
>> >>>> is basically the same as
>> >>>> foo.segment<dim_A>(0 ) = A;
>> >>>> foo.segment<dim_B>(dim_A ) = B;
>> >>>> foo.segment<dim_C>(dim_A+dim_B) = C;
>> >>>
>> >>>
>> >>> yes, in theory it's what happen in that order. but in that case
>> >>> Arnaud's 1st example should fail regardless on the compiler. So there
>> >>> might a c++ subtlety I'm missing.
>> >>
>> >>
>> >> I assume the compiler does some over-optimization here, i..e., loads
>> >> values of foo and starts evaluating the product before beginning to
>> >> write to foo. I don't know if that kind of optimization is allowed by
>> >> the C++ standard (it would not surprise me if it was).
>> >
>> >
>> > I just found this:
>> >>
>> >> However, an invocation of an overloaded comma operator is an ordinary
>> >> function call; hence, *the evaluations of its argument expressions are
>> >> unsequenced* relative to one another (see 1.9).
>> >
>> > as an answer here:
>> >
>> > http://stackoverflow.com/questions/7784774/is-comma-operator-free-from-side-effect
>> > So it seems there is no guarantee on the evaluation order for overloaded
>> > comma operators.
>> >
>> >
>> > Christoph
>> >
>> >
>> >
>> > --
>> > ----------------------------------------------
>> > Dipl.-Inf., Dipl.-Math. Christoph Hertzberg
>> > Cartesium 0.049
>> > Universität Bremen
>> > Enrique-Schmidt-Straße 5
>> > 28359 Bremen
>> >
>> > Tel: +49 (421) 218-64252
>> > ----------------------------------------------
>> >
>> >
>>
>>
>