Re: [eigen] Support for true Array |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Support for true Array*From*: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>*Date*: Fri, 6 Nov 2009 14:51:25 -0500*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=ckDMefqv1OZl0LbIQTJSLIlxHQrk8jrgQ9N1gfuUoIU=; b=pa/+QW6GCsLo5ylM5aeLyugiTuhdR13OHk7w0JSXkhpxT+5uwWsipQNm5agENBCZoz J4adylc22PXPQ7y8Uaq3O4pYVkQGiR9Kw63KBsn/Yyg5mgCyvFOoT+Zs7jAoMPTHAKgv v62DUy+mMy+IU0RAFETlrj2YpzLJhwgMYfTRc=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=cvG4ikITWfUwfruJaJ97HldTxkDRa2K5E7FDY1U4mlZ924mRA/nH2y8g46rUsK1KEJ JpZ8MYlwVVMY/Tn3e+46ERr3PIgvQu+rX3LM3qZB5jIVCmbk9RIJHmpiMKqh4M4TXq7V IYmF1QQ+BMNn8JNIjFrbQ5TpN6H4X+8n1lDUg=

2009/11/6 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>: > > Hi, > > I now we already have way too much modules/features which have to be > polished before thinking about new features, but anyway, let me do this > proposal. > > Eigen has a very good support for mathematical matrices. Even though many > kind of array-like operations can be performed on our matrices via the > cwise() prefix, we are still lacking a true support for array of scalars. In > particular, it would be very convenient to have an Array class that you > could use just like a scalar value, all operations being berformed > coefficient wise. I often thought about some options to Matrix/MatrixBase > for that, but this is rather ugly and prone to many mistakes. OK, assuming there is a reasonable implementation for that (and there is, i agree with your proposal) then this is useful to have in Eigen. Even if we wanted to claim that Eigen is 100% focused on matrices, this would still be useful for the following reason. Eigen currently only does "vertical" i.e. "per-object" vectorization. Which is perfect for large objects, but not perfect for small objects which may not be efficiently divided into packets. With your proposal, if a have a million of Vector3f's, i could instead do a Vector<array,3,1> and all operations on it would get automatically vectorized, which is supercool as per-object vectorization is hard/impossible in this case. This advantage of horizontal vectorization is going to be even more important with future SIMD such as Larrabee as the packet size gets bigger. > > So here the idea is to mimic what is done for AutoDiffScalar, > DiagonalMatrix, Quaternion, etc. Basically, the principle is wrap a > MatrixBase object (a matrix or an expression) into a wrapper class providing > a different, specialized API. In practice this is implemented by defining an > ArrayBase class supporting basics operators and the math functions of the > standard library (no a.sin(), but std::sin(a)). Then we define two derived > classes providing the actual coefficients: > - A class Array<Scalar,Rows,Cols> providing storage and convenient ctors. It > would basically store a Matrix<Scalar,RowsCols>. > - A class ArrayWrapper<Expression> wrapping any MatrixBase expression as an > Array (mostly for internal use to enable expression templates and, e.g., to > view an existing Matrix as an Array, etc.). > > To make thing even more clear, here is the implementation of operator* and > std::sin: > > template<typename OtherDerived> > ArrayWrapper<CwiseBinaryOp<ei_scalar_multiple_op<Scalar>, typename > Derived::Coefficients, typename OtherDerived::Coefficients> > ArrayBase<Derived>::operator*(const ArrayBase<OtherDerived>& other) const > { > return matrix() * other.matrix(); > } OK, I understand. The cool thing in your idea is that we don't have to code again all the expression templates, instead we use existing expression classes wrapped in ArrayWrapper. That makes me wonder, perhaps the exact same idea should be applied also to Quaternion where a recent thread on this list suggested that expression templates are useful too (as non-gcc compilers are not able to understand that everything fits in registers). > > namespace std { > > template<typename Derived> > ArrayWrapper<CwiseUnaryOp<ei_scalar_sin_op<Scalar>, typename > Derived::Coefficients> > sin(const ArrayBase<Derived>& a) > { > return a.matrix().cwis().sin(); > } > > } I see. I understand how it makes sense to define std::sin here but i think we should also define ei_sin so that array type can be seamlessly used as the scalar type with the rest of Eigen. > Following the AutoDiffScalar implementation, all of this can be done using a > couple of macros to reduce coding and maintainability efforts. > > A good thing is that can be done without any change in the core of Eigen, > and so one can do it totally outside Eigen. Yes, this is an extra bonus. However, since this doesn't seem like too much extra code, perhaps this should go into the existing Array module. That would also solve a problem with naming! > > What do you think ? *kisses* Benoit > > gael. > >

**References**:**[eigen] Support for true Array***From:*Gael Guennebaud

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] AutoDiffScalar** - Next by Date:
**[eigen] merging eigen2-cminpack** - Previous by thread:
**[eigen] Support for true Array** - Next by thread:
**Re: [eigen] Support for true Array**

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