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

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: This topic is complex number portability, not Re: [eigen] FFT for Eigen*From*: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>*Date*: Wed, 20 May 2009 15:55:23 +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=0YudEPNdB5fGe4v7PTQEsbRPmlAEZtIMyBm+zx5qPtI=; b=hiawQMnCSEcZ88Fc+KCSjzNF5/mOeFJPPeRZcwRM+eYAPyuCKaAxUTGBo5fbnWyu9p jQxjAoqH7dWbdm2JIJk7oUoIKY7P/zLyAKm0L2vwkwC+g1HxqsPEwsSlt3FEmFpMa9ae nxPzJ2i2/o7EOM+l/QshFotfX6avkJR+6MWBg=*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=QIfwxCdMUX5NvKilRHETl2NY08xC6su78Ip/5GNtDnzpGf7n+AOdr+sspr3Kc7cjyM +FESXKeOdK3xSJu2z+lAJ5HZI4m+Sbgv6NbSbzqsbBLywG2oWasmVVL1rv/NAUfARecn swy0j6ZUw+uRUEHPAA3eiZ6GGP3j23vbvTs6g=

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

**References**:**[eigen] FFT for Eigen***From:*Mark Borgerding

**Re: [eigen] FFT for Eigen***From:*Ricard Marxer Piñón

**Re: [eigen] FFT for Eigen***From:*Gael Guennebaud

**Re: [eigen] FFT for Eigen***From:*Benoit Jacob

**Re: [eigen] FFT for Eigen***From:*Gael Guennebaud

**Re: [eigen] FFT for Eigen***From:*Gael Guennebaud

**Re: [eigen] FFT for Eigen***From:*Benoit Jacob

**Re: [eigen] FFT for Eigen***From:*Benoit Jacob

**Re: [eigen] FFT for Eigen***From:*Gael Guennebaud

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

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Unifying decomposition interfaces** - Next by Date:
**Re: [eigen] Unifying decomposition interfaces** - Previous by thread:
**This topic is complex number portability, not Re: [eigen] FFT for Eigen** - Next by thread:
**std::complex standard packing requirements was Re: [eigen] FFT for Eigen**

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