Re: This topic is complex number portability, not Re: [eigen] FFT for Eigen

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


note that here m1 and m2 are matrices of complex numbers, not
std::complex<>. Internally they use some reinterpret_cast assuming a
std::complex<T> as same storage than T array[2].

Gael.

On Wed, May 20, 2009 at 3:14 PM, Mark Borgerding <mark@xxxxxxxxxxxxxx> wrote:
> (Let me try one more time to change the email subject to reflect the
> offshoot conversation :)
>
> Gael Guennebaud wrote:
>>
>> according to other discussions, I committed this change, so, e.g.,
>>
>> m1.real() = m2.imag() + m3;
>>
>
> AFAIK this is not standard c++  and it fails on at least some older
> compilers: g++  (GCC) 3.2.3 20030502 "non-lvalue in assignment"
>
> According to
>  http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387  it may
> not become standard either since the committee seems to favor mutator
> functions over lvalues.
>
> The safe "standard" way to do it is something like:
>   template <typename _Complex, typename _Scalar>
>   void set_real( _Complex & a,  const _Scalar & b) {    a  =  _Complex( b ,
> a.imag() ); }
> (warning: above has not been compiled)
>
> If we tiptoe just a little off the standard path, lets' assume the array[2]
> layout, which is a fairly safe assumption, then the following should work:
>   reinterpret_cast<_Scalar(&)[2]>(a)[0] = a_real_value
>   reinterpret_cast<_Scalar(&)[2]>(a)[1] = an_imag_value
> and is probably easier for the compiler to optimize correctly.
>
>
> -- Mark
>
>
>



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