Re: [eigen] FFT for Eigen |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] FFT for Eigen*From*: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>*Date*: Wed, 20 May 2009 13:46:13 +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=QidXZ/EYcbvDD6CiRTKgzu3MunWOE2bZGX59Elrg08k=; b=BTdjQ20RDglWv80mO4TxgEivoXvfOHLFORD2+yDkfXpFOueq6vdPf7+A+oLylliabH i8TEBxwBRwaCtDnmE8/Tf3UiGGiK+oBgFnKZ3fUibQ3FX4uxWTNUgdEkCgZvTBtnpUlO 2CQxEXOnjEtsWzIB+ZsLsKilqWh35daehoRc8=*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=B3/QHyShYtVqJI32krPyqwUj94orQV880FUZUYMPhGsBsvp3upAzSb9Ogy69kHnb6f FW+EDv0uGCuL5i3w/G23hGpQRd+R+J89OsLtuA//C9lUNGR+MMNzPVfnTK19aOQZ0egh c2f5UeMH+3fynpwYFzes+tBBH/f4hPhQmL1Tk=

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

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

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

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

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

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

**Messages sorted by:**[ date | thread ]- Prev by Date:
**[eigen] Unifying decomposition interfaces** - Next by Date:
**[eigen] Sparse -- Diagonal product** - Previous by thread:
**Re: [eigen] FFT for Eigen** - Next by thread:
**This topic is complex number portability, not Re: [eigen] FFT for Eigen**

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