Re: [eigen] Eigen Types as Parameters for Functions

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


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





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/