Re: [eigen] Eigen::Complex attempt

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

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