Re: [eigen] Custom expression type API stability
• To: eigen <eigen@xxxxxxxxxxxxxxxxxxx>
• Subject: Re: [eigen] Custom expression type API stability
• From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
• Date: Thu, 18 Feb 2016 18:57:42 +0100
• 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; bh=6Mt8NB8sFqxjQBffy3Sm5YurYR+MBKNGNBlXge27k/0=; b=SbLHKFVydReySt7CvlmxXgniWw7mdYmiNLxr0VRPdVtoyvw2P4hWcEiewkADM3YNJN y9z8BO0tB15jk0a+ZgVgWIcGFtks8Iw5OcjB02ZdAqNomuLuXg8x/jYqoypQP6Y2Fw0i Pu//n3iuNJNRGLEoywiajw+wK6Ig/eVKihLV18Nn+CZ8RmShKn+UUHoD4GgbLKuat03N M1eXzKMZaX2BdlHwL2z7YPSMbKfmtBr6hiLXGowcWffetXtYZgI1q72Nr+bPP+2JaCV5 Cv+ls32CyifqCM2wLr8uoQD8giWmpd2M8/wjZmOKD/SLM2lZGqFhoI2M0Q30Aq0ovMyQ YAPw==

On Thu, Feb 18, 2016 at 1:46 PM, Dan Čermák wrote:
I need basically two different expressions:

1. given two vectors:
cond_vec and choice_vec -> result(i) = choice_vec(i) if cond_vec(i) > 0
else choice_vec(i+1)
this is rather simple and maybe doable otherwise (and I have already managed
that using the 3.3 development version, although it's probably ugly)

2. calculate reductions of 3d matrices times 2d matrices (they are not stored
fully, since they can be calculated fairly easily from e.g. a matrix and a
vector, or are highly sparse): result(i) = Sum_j,k M_ijk * K_jk (as a full
reduction) or result(i,j) = Sum_k M_ikj * K_kj
I would like to create some abstraction where I only need to provide a
function which calculates the elements or row/col of the contraction result..

Since M and K are not even Eigen matrices, then you can workaround with a nullary-functor, e.g.:

res = MatrixXd::NullaryExpr(rows,cols,your_fancy_functor(M,K));

where your_fancy_functor has to implement an operator()(Index i, Index j) method.

And of course you can hide the construction of the nullary-_expression_ using a free function, so that you simply has to call:

res = fancy_product(M,K);

gael

Cheers,

Dan

On Thursday 18 February 2016 12:10:07 Gael Guennebaud wrote:
> Indeed, writing custom expressions still requires to play with
> Eigen::internal, meaning that it is subject to change in the future. As you
> noticed, the current 3.2 way is different than the future 3.3 way. If you
> tell us a bit more about your need for a custom _expression_ we might be able
> to guide you towards the best approach. Maybe you don't need a new one at
> all, maybe ReturnByValue if good for, etc.
>
> cheers,
> gael
>
> On Thu, Feb 18, 2016 at 11:06 AM, Dan Čermák <dan.cermak@xxxxxxxxxxxxxxxxxxx
> > wrote:
> >
> > Hi Folks,
> >
> > I have a question concerning adding custom _expression_ types as described
> > here:
> > http://eigen.tuxfamily.org/dox-devel/TopicNewExpressionType.html . I am
> > currently developing a program that would require some custom _expression_
> > types
> > to be efficient.
> > Is the way how they are implemented expected to change during the next
> > versions? Since I could not compile the example with Eigen 3.2.7 and
> > 3.2.8,
> > only with the latest snapshot from mercurial.
> >
> >
> > Cheers,
> >
> > Dan

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