Re: [eigen] Eigen Types as Parameters for Functions

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

FYI, an improved version has been committed:

https://bitbucket.org/eigen/eigen/changeset/a34b903ce4b5/
changeset:   a34b903ce4b5
user:        ggael
date:        2012-07-05 17:00:28
summary:     Bug 481 step 1: add a new Ref<> class for non templated
function arguments


gael

On Mon, Jul 2, 2012 at 4:53 PM, Gael Guennebaud
<gael.guennebaud@xxxxxxxxx> wrote:
> Thanks Christoph, I tend to agree with you.  I've uploaded a new
> version with extended usage examples there:
>
> http://eigen.tuxfamily.org/bz/show_bug.cgi?id=481
>
> gael
>
>
> On Mon, Jul 2, 2012 at 12:47 PM, Christoph Hertzberg
> <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>> On 02.07.2012 12:06, Gael Guennebaud wrote:
>>>>>
>>>>> That's the solution I wanted to suggest. I proposed to pass the Ref<>
>>>>> objects by value mostly because it looks better for writable
>>>>> arguments. Having a "const Ref<VectorXf>&" writable is a bit
>>>>> dangerous. But if we agree that copy-back is a no go, then the
>>>>> internal m_object will exists only for const version so one could pass
>>>>> by a const reference for const arguments, and by value for writable
>>>>> ones.
>>>>
>>>>
>>>>
>>>> Yes, sounds like a plan. This should cause no overhead if the m_object is
>>>> not required, just some temporary stack space.
>>>> Furthermore, this can then be used for (fixed size) aligned references as
>>>> well, copying the expression, iff it is not aligned at compile-time.
>>>
>>>
>>> Since we are fine-tuning the expected behavior, I wonder whether we
>>> should allow implicit evaluation for inputs having "direct-access".
>>> Let's consider a function foo1 taking a "const Ref<const VectorXf>&"
>>> as argument. It is expected that the following calls yield an
>>> evaluation into a temporary:
>>>
>>> foo1(a+b);
>>> foo1(-a);
>>>
>>> However, when the input argument references an object with storage, an
>>> implicit evaluation might be surprising as in the following cases:
>>>
>>> foo1(A.row(i));
>>> foo1(b.imag());
>>>
>>> If we forbid such cases, in practice this means the user will have to
>>> explicitly call .eval() in such cases. This behavior would also be
>>> coherent with the non-const version for which 1) the input argument
>>> has by construction "direct-acces", and 2) we already stated that
>>> implicit evaluation into a temp would be too risky.
>>>
>>> On the other hand, if we do so, I already see users coming back to us
>>> with statements as "foo(1*A.row(i)) compiles but foo(A.row()) does
>>> not, wtf?". So I'm a bit puzzled here.
>>
>>
>> I would suggest allowing both (and evaluate into a temporary iff necessary).
>> If you then mention in the documentation that direct access types which do
>> not fit the memory layout of Ref<> are evaluated into a temporary, nobody
>> should have legitimate complaints about that behavior -- it would be
>> basically the same problem/feature that C++ implicitly evaluates expressions
>> to const references if possible.
>>
>> If there is a need for prohibiting implicit evaluations, we could introduce
>> another Ref<> specialization which never evaluates.
>> Maybe Ref<VectorXd>, Ref<const VectorXd> and Ref<const VectorXd&> (with only
>> the second evaluating), or add an Options flag after to the Strides
>> parameter.
>>
>>
>>
>> Christoph
>>
>>
>>
>> --
>> ----------------------------------------------
>> Dipl.-Inf. Christoph Hertzberg
>> Cartesium 0.049
>> Universität Bremen
>> Enrique-Schmidt-Straße 5
>> 28359 Bremen
>>
>> Tel: +49 (421) 218-64252
>> ----------------------------------------------
>>
>>
>>
>>