[eigen] About Complex numbers Todo |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: [eigen] About Complex numbers Todo*From*: Bastien ROUCARIES <roucaries.bastien@xxxxxxxxx>*Date*: Fri, 20 Aug 2010 10:31:08 +0200*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=GXMnvrk5BX6MZ28VbgR7UcjCAm+BzT/crX0JAz2ofCk=; b=TcIxXcCI0omJcKdc0cti5LysIpZeRdSJZ0dhP0grwvwNe07SXimJbJT4RxgYRNZidR 5VAFEVgxg7w8F0f9GcJMonjYAeG5UxfEWy1E0p9q6WAcCs/4cGS1e3uCWIHikj9peYuE 9TY9TwU9Jc52vq9iVG0th0EJ+B+1IIRXrG1Yg=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=nH/eG6CdJA9qZNlOn/5DIt7jd6vdiu6nkvNVNtMCDES8TDuO44hFaVfgg0/qxHDRfQ 2fUIIFlY4vhrOzg72T/opRu5RGouiTYZPF+nVjsufIM2rMIrH/7Df66oYtg/lGijfTFr 2NQ+c2Ttkt6TuJhVWkvILMIQ2S51bOH1DadVk=

Hi, It seems that the rationale of implementing a new complex class could disappear. According to the draft of the next standard C++0x (at this proposition is well acknowledged since 2002 see below): Section 26.4 p 886 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf) say that complex is always an array (I have quote at the end of the mail), the wording was especially choosen in order to be Fortran compatible and C99 compatible (see http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#387 and the last remark about "All existing implementations already have the layout proposed here"). Thus I think we could remove this todos item, if you want to be safe you could publish a test case and use crash the compilation. I could write a cmake test case if you want Bastien The standard: 2 The effect of instantiating the template complex for any type other than float, double, or long double is unspecified. The specializations complex<float>, complex<double>, and complex<long double> are literal types (3.9). 3 If the result of a function is not mathematically defined or not in the range of representable values for its type, the behavior is undefined. 4 If z is an lvalue expression of type cv std::complex<T> then: — the expression reinterpret_cast<cv T(&)[2]>(z) shall be well-formed, — reinterpret_cast<cv T(&)[2]>(z)[0] shall designate the real part of z, and — reinterpret_cast<cv T(&)[2]>(z)[1] shall designate the imaginary part of z. Moreover, if a is an expression of type cv std::complex<T>* and the expression a[i] is well-defined for an integer expression i, then: — reinterpret_cast<cv T*>(a)[2*i] shall designate the real part of a[i], and — reinterpret_cast<cv T*>(a)[2*i + 1] shall designate the imaginary part of a[i].

**Follow-Ups**:**Re: [eigen] About Complex numbers Todo***From:*Carlos Becker

**Messages sorted by:**[ date | thread ]- Prev by Date:
**[eigen] Optimization Algorithms** - Next by Date:
**Re: [eigen] About Complex numbers Todo** - Previous by thread:
**Re: [eigen] Optimization Algorithms** - Next by thread:
**Re: [eigen] About Complex numbers Todo**

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