Re: [eigen] FFT for Eigen

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

according to other discussions, I committed this change, so, e.g.,

m1.real() = m2.imag() + m3;

is now working.

Gael.

On Tue, May 19, 2009 at 10:51 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> So unless this turns out to be safe, I'd rather add that to our list
> of excuses for adding our own complex class (in addition to continued
> support for std::complex).
>
> Benoit
>
> 2009/5/19 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
>> I'm OK if this doesn't crash.
>>
>> If the STL clearly specifies that the two coords in a complex<> are
>> stored as an array, then it's OK.
>> If on the other hand, some implementation stores the 2 coordinates as
>> just 2 separate members, and someone compiles this with a strict 64
>> bit alignment, then with complex<float> that will crash.
>>
>> Benoit
>>
>> 2009/5/19 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>>>>> Really? The only real() that I can see is const, and anyway, how would
>>>>> we implement that? std::real() and std::imag() only return references
>>>>> with certain GCC implementations while e.g. on GCC 4.0 / Mac they
>>>>> return by value.
>>>>>
>>>>> It seemed to me that allowing that was one of the things that would
>>>>> require us to have our own complex numbers class.
>>>>
>>>> arf, you are right., one more stupid annoying std limitation....
>>>>
>>>
>>> ok, so, is anyone against adding that:
>>>
>>> inline float& ei_real(std::complex<float>& x) { return
>>> reinterpret_cast<float*>(&x)[0]; }
>>> inline float& ei_imag(std::complex<float>& x) { return
>>> reinterpret_cast<float*>(&x)[1]; }
>>>
>>> so that we can have real() returning a lvalue ?
>>>
>>> Gael.
>>>
>>>
>>>
>>
>
>
>