Re: [eigen] Eigen::Complex attempt |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Eigen::Complex attempt*From*: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>*Date*: Wed, 17 Jun 2009 17:50:40 +0200*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=JzwEI2SdZZM/T5cARZQJwSrp70eAqT5vpDQrxCrKJSQ=; b=ien+TCWopv3e7On1vK8sCM3NxyiFIiTC9H8MkIRnZFTn8AqW/a7tJ3fvaONOl9HnYj GwAyIDuJNlgwN+Wb+v068+OcMAov/Tr+qKE0ABSWOjmxH673PW1BKCiDzWcePiR4Y7lo ks8ScVpHGUxnLwx30/XhjFOyucccS39fitdzU=*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=F5TeXfqPI/1tcZhvXyxrHzgTj2MNwzp+6rIF7L4eM1tcVwixQIv/HEAq91InIH6whg aszqgk+oGhJUsokpylVw1CIkb9dIXv9WZDLLmjz3Y1r5wRwBIM0ayiuoR/BI43U59fIw hxPfSAKhqZW4qG2i8NFbfE02JkXN2F8TEkJQM=

Hi, thanks for this good start. Since we already manage to implement writable MatrixBase::real() and MatrixBase::imag() functions (using a reinterpret_cast) I thought the only reason to add our own Complex type was to be able to vectorize it for double. In that case, the easiest thing to do is to make Complex stores an Eigen::Matrix<T,2,1> and re-implement the basic operators like this: inline template<typename T> Complex<T> Complex<T>::operator+(const Complex& other) const { return Complex(this->m_ri + other.m_ri); } for the complex product we'll have to to it based on the architecture (see for instance the quaternion product) gael. On Wed, Jun 17, 2009 at 4:44 PM, Mark Borgerding<mark@xxxxxxxxxxxxxx> wrote: > Benoit Jacob wrote: >> >> 2009/6/17 Mark Borgerding <mark@xxxxxxxxxxxxxx> >> >>> >>> I just started out by trying to see if I could make the Complex class >>> have an operator & which returns a "pointer object" that could be converted >>> to either >>> Eigen::Complex<T> * >>> or >>> std::complex<T> * >>> That worked and then I just didn't know when to quit. So now here is a >>> Complex class that has a superset of the std::complex interface and actually >>> uses std::complex whenever it can. It has more accessors and mutators. >>> >>> >>> http://bitbucket.org/mborgerd/eigen2_for_fft/src/tip/unsupported/Eigen/Complex >>> >>> Note the structure packing should be identical (assuming the C++ >>> standards folks are correct in their assessment that "All existing >>> implementations already have the layout proposed here." >>> http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387 ) >>> >> >> Ah, thanks a lot for finding this link! This is enough to make me OK >> to make this assumption. >> >> If I understand well, your aim is to make Eigen::Complex entirely >> interoperable with std::complex, and the tricky part was indeed to >> handle pointers, good job. >> >> (I'm not yet able to really review anything). >> >> Benoit >> > > > To be honest, I think I may have wasted my time duplicating the entire > std::complex interface. If I had stopped to think for a moment, I think I > would've chosen to simply derive the Eigen::Complex<T> class from > std::complex<T>. The avoidance of subclassing an STL type is so deeply > ingrained in me that it simply never occurred to me. > > If we are willing to buck convention, there are some goodreasons to make > Eigen::Complex a subclass of std::complex: > > * Complex should support all the same functions that std::complex > has, plus more > * current attempt already assumes same structure size & packing > * reduce testing workload > * reduce lines-of-code footprint > * remove possibility that a trivial operator/method wrapper will NOT > be optimized away > > Here are reasons we might NOT want to make Eigen::Complex a subclass of > std::complex > > * If we cannot assume a compliant std::complex (note current effort > assumes this) > * If we cannot assume a compatible structure packing (see above > discussion) > * If we need destructor actions for Eigen::Complex ( std::complex > destructor is not virtual) > * If we wish to override and change the behavior of a std::complex > operator (seems like a good way to anger users) > * IIRC, method name resolution gets error-prone, e.g. if we make a > Complex::real() method, then name lookup rules will not > automatically use any std::complex::real() method > * It is generally *regarded* as bad practice to subclass from a std > type. This is not a technical disadvantage per se, but more a > psychological one. > > What else am I missing? Can anyone come up with other reasons for or > against subclassing std::complex? > > > -- Mark Borgerding > > >

**References**:**[eigen] Eigen::Complex attempt***From:*Mark Borgerding

**Re: [eigen] Eigen::Complex attempt***From:*Benoit Jacob

**Re: [eigen] Eigen::Complex attempt***From:*Mark Borgerding

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Eigen::Complex attempt** - Next by Date:
**Re: [eigen] [Patch] fix typo** - Previous by thread:
**Re: [eigen] Eigen::Complex attempt** - Next by thread:
**[eigen] [Patch] fix typo**

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