Re: [eigen] Lazy evaluation bug, feature, or PEBKAC?

[Eamon Nerbonne <eamon@xxxxxxxxxxxx>]

Hi all,

C++0x is going to happen, and this particular bug (even if user caused) will be easier to make since auto is so attractive for templated types one (as a programmer) doesn't well understand.  Despite the low runtime cost, there still is a motivation to do this 
just to simplify complicated expressions without binding _expression_ 
decomposition to _expression_ evalutation strategy (probably not common, but I could see myself doing this).  If I understand correctly, without explicit eval, this will work in eigen3 - right?  And with explicit eval, even doing "const auto &" won't be enough?

In any case, a note "be careful with auto" might be useful in the docs.

--eamon@xxxxxxxxxxxx - Tel#:+31-6-15142163

On Wed, Mar 2, 2011 at 19:45, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:

2011/3/2 Dave Steffen <dave.steffen@xxxxxxxxxxx>:
> On Wednesday, March 02, 2011 11:07:19 am Benoit Jacob wrote:
>> 2011/3/2 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
>> > 2011/3/2 Dave Steffen <dave.steffen@xxxxxxxxxxx>:
>> >> On Wednesday, March 02, 2011 02:31:40 am Gael Guennebaud wrote:
>
> [...]
>
>> >>  In my application, I really *do* need to add two matrices, which
>> >>  might or might not happen to have 1 column, and then operate
>> >>  (read-only) on individual columns.  That doesn't strike me as a
>> >>  terribly unusual thing to do.
>> >
>> > The unusual thing here is to want to construct the _expression_ object
>> > once and then reuse it.
>> >
>> > Constructing these _expression_ objects has zero runtime cost in
>> > optimized builds, because we make it very easy for the compiler to
>> > optimize away the _expression_ objects completely.
>> >
>> > Therefore, there is no overhead in doing "a+b" everytime you need this
>> > sum _expression_: zero overhead.
>> >
>> > That's why practically nobody is trying to do what you're doing here :)
>>
>> Also, note that your code only looks "natural" because it's using the
>> C++0x auto keyword. The C++03 version would have to name explicitly
>> the (very abstruse) _expression_ type, which is another reason why
>> practically nobody bothers.
>
>  Riiiight.  That is, I shouldn't be stashing a ref to an
>  *_expression_*, I need to be evaluating that _expression_ into a Matrix.

Either that, or do what I suggested in my previous email: just write
(a+b).col(0) everytime. Neither the operator+ nor the col() method
have any cost at runtime.

Benoit

>
>  Being new to Eigen, it didn't occur to me that keeping refs to
>  expressions could wreak so much havoc.
>
>  So: the actual answer to my question is both "bug" and "PEBKAC",
>  the latter problem to be resolved by the usual statement: "don't do
>  that".
>
>  :-)
>
> --
> Dave Steffen, Ph.D. - Software Engineer
>
> Numerica Corporation <http://www.numerica.us>
> 4850 Hahns Peak Drive, Suite 200
> Loveland, Colorado 80538
> main (970) 461-2000 x 227   direct (970) 612-2327
> Email: dave.steffen@xxxxxxxxxxx
> fax (970) 461-2004
>
> This message and any attachments are intended only for the individual
> or entity to which the message is addressed.  This is a private
> message and may contain privileged information.  If you are neither
> the intended recipient nor the agent responsible for delivering the
> message to the intended recipient, you are hereby notified that any
> review, retransmission, dissemination, or taking of any action in
> reliance upon, the information in this communication is strictly
> prohibited, and may be unlawful.  If you feel you have received this
> communication in error, please notify me immediately by returning this
> email to me and deleting it from your computer.
>
>
>