|Re: [eigen] Eigen Types as Parameters for Functions|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Eigen Types as Parameters for Functions
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Thu, 5 Jul 2012 17:06:49 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=vQmsHuw52ffI/xPblzYbnSElDv9nGwqsMl0qxdMokGA=; b=nK/7rA7LiXo+hAcz9Le8Cuk0jbxncYhOl2zi9De3S2UwJn/s4hPY6FY9FD2MRVyj4D oCM3pss4V/i2FdPBU8ypv7TjxQLTmNzMPNgN7WhbhkdnqDNteUtNE2bvOgo0Ib07jjp8 qgRReQfEwjByoQFSxZEXY6uPoWKLhg6rOBHzlI+bE913GLpfupbDbx+Ttal6QLqQxI2R UXxvRu/vfco6T5CrOyvHkYWE4elk6MlBfatB7R4lmUaF0lNVWwruWWLVgNg2rReGqQHx FkdA0O71trOy3giwyYbBp8c9pneBda2JBn/l9xPBsNHxFae3rD5ohFvZg2CDFBmRX4Mj vl/w==
FYI, an improved version has been committed:
date: 2012-07-05 17:00:28
summary: Bug 481 step 1: add a new Ref<> class for non templated
On Mon, Jul 2, 2012 at 4:53 PM, Gael Guennebaud
> Thanks Christoph, I tend to agree with you. I've uploaded a new
> version with extended usage examples there:
> 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
>>>> 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:
>>> However, when the input argument references an object with storage, an
>>> implicit evaluation might be surprising as in the following cases:
>>> 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
>> Dipl.-Inf. Christoph Hertzberg
>> Cartesium 0.049
>> Universität Bremen
>> Enrique-Schmidt-Straße 5
>> 28359 Bremen
>> Tel: +49 (421) 218-64252