220 32091 <5fc8b8b9-c0f6-4620-b54a-62acde6cb7f0@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: 3dw4rd@verizon.net Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Decomposition of std::complex. Date: Fri, 14 Apr 2017 13:01:17 -0700 (PDT) Lines: 1011 Approved: news@gmane.org Message-ID: <5fc8b8b9-c0f6-4620-b54a-62acde6cb7f0@isocpp.org> References: <74a45396-2e35-4231-86b9-4caceb531239@isocpp.org> <4259d7dc-f060-dc27-5004-37bf4726e456@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1227_1652640001.1492200077632" X-Trace: blaine.gmane.org 1492200080 31992 195.159.176.226 (14 Apr 2017 20:01:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 14 Apr 2017 20:01:20 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCS2FYFYXYEBBDWVYTDQKGQEDQLQH6Q@isocpp.org Fri Apr 14 22:01:14 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f197.google.com ([209.85.192.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cz7P7-00089L-Rw for gclcip-std-proposals@m.gmane.org; Fri, 14 Apr 2017 22:01:14 +0200 Original-Received: by mail-pf0-f197.google.com with SMTP id j16sf51626073pfk.4 for ; Fri, 14 Apr 2017 13:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=3eP2sRpxzVeXV7hpO6J1LTXgDInmSGvlX8UQ3t61yf8=; b=xUV22rhmx9HbC8Ja4m7kmcOYkY3TUUGo+Ewe0vPLED71i48bi7zl7coFvXzCJl5jXS U3SFvm7Z9WzEKa1sOLmS/33Ne0ckrdImi6Nh2LzFAH2PW8+TY1crmed5LpHyeBYlAYzV XeYIH6D3Vi6rZf4bqHt/JleDYGOyq4VqAcYNbGFJslBOrCHQ9/dNs7giZjBelYdUQWZg Rdw0oT8w2SsZc339Z2P+DK6nXe11mfZK4BKTIxm7mkaXzimsaGdItkTCAmIOBT11raES +mf9/ToP4sOif9UVEN3rpXcJRrPlhpQEpw0a7B9X4pXJZ5J4Vz+SYBDmLU6Ui5xsiskU eOsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=3eP2sRpxzVeXV7hpO6J1LTXgDInmSGvlX8UQ3t61yf8=; b=U42Y0urXC4r0C6So1tZ3KtRGKbVTtiEoCInCvJeDriFYUyECNUDMToAglONLwgaP2M 4hOrTYFHnkb65VoSImfflRHojGxb80EHu5nS7OblPYLX5JExdkD4kBG676smlE4nd13q 51PpqCikbYYYeWyxtoGyyMtAC4E4k3/IGGwWUd1CEY8dPnDtwfb/kHG0nMOtjhO9Ioxv RdYlnu9oQm06Ul5JC3Zs7f9kKKjKKW/olbPSVuB7FNcLk5pVHSP3PyMZFBEhadnj2dws EZBKcuPPs6jIMzvaqwdg81oRMdcY+906LtvQYWTpl5zwx4mvuHaiy4PpNFXZaxwlQQyO quag== X-Gm-Message-State: AN3rC/5FRbhTupM4SdnQ44YtClNcsao3f9UO9fqCWH6AQq+fqnRnJ8T7 F+z9lk2Frva6VA== X-Received: by 10.99.63.139 with SMTP id m133mr1769248pga.42.1492200079034; Fri, 14 Apr 2017 13:01:19 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.17.116 with SMTP id p49ls5385743otp.4.gmail; Fri, 14 Apr 2017 13:01:18 -0700 (PDT) X-Received: by 10.157.17.171 with SMTP id v40mr199354otf.11.1492200078127; Fri, 14 Apr 2017 13:01:18 -0700 (PDT) In-Reply-To: <4259d7dc-f060-dc27-5004-37bf4726e456@wanadoo.fr> X-Original-Sender: 3dw4rd@verizon.net Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:32091 Archived-At: ------=_Part_1227_1652640001.1492200077632 Content-Type: multipart/alternative; boundary="----=_Part_1228_1846414457.1492200077635" ------=_Part_1228_1846414457.1492200077635 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Friday, April 14, 2017 at 1:02:02 PM UTC-4, Vicente J. Botet Escriba=20 wrote: > > Le 14/04/2017 =C3=A0 00:11, 3dw...@verizon.net a =C3=A9crit= : > > In many uses of std::complex > one wants to capture the real and imaginary parts in separate variables= =20 > either to use them in subsequent calculations or to modify them=20 > individually. > There are many options: > > These options reflect an over-encapsulation of std::complex, which=20 > everyone agrees is a struct with two floating point numbers, real part an= d=20 > imaginary part, in that order. > Attempting to use a decomposition declaration for a complex number is an= =20 > error because of the pretension (ostensibly for C compatibility) the=20 > complex numbers are opaque. > > Humm, it is not so opaque as you can get the representation as a c-array. > > This means that we should already be able to apply structured binding=20 > using the cast > > auto& [p, q] =3D reinterpret_cast(z); > This is certainly legal now. That's how I implement this. It's just fugly= =20 and obscure for users. > Nevertheles I agree with you that your proposal makes this cleaner and=20 > more explicit. Complex should be a ProductType. > > > The rvalue and lvalue decomposition of std::complex can be accomplished= =20 > with a simple pure-library extension: > Provide a tuple interface to std::complex. > > // Tuple interface to class template complex. > #define __cxx_lib_tuple_complex 201705 > > // Declare tuple_size. > template > class tuple_size; > > // Partial specialization for std::complex. > template > struct tuple_size> > : public integral_constant { }; > > // Declare tuple_element. > template > class tuple_element; > > // Partial specialization for std::complex. > template > struct tuple_element<_Int, std::complex> > { > static_assert(_Int < 2, "index is out of bounds"); > typedef RealTp type; > }; > > // Decompose complex as rvalues. > template > constexpr const RealTp > get(const std::complex& z) > { > static_assert(_Int < 2, "index is out of bounds"); > return _Int =3D=3D 0 ? z.real() : z.imag(); > } > > // Decompose complex as lvalues. > template > constexpr RealTp& > get(std::complex& z) > { > static_assert(_Int < 2, "index is out of bounds"); > auto w =3D reinterpret_cast(z); > return _Int =3D=3D 0 ? w[0] : w[1]; > } > > > I believed that this reinterpret_cast was UB, but as you note below, it i= s=20 > defined by the standard. > > > Then we have the following behavior: > > template > void > test_complex_decomp() > { > std::complex z(1, 2); > > auto [x, y] =3D z; > std::cout << "z =3D " << z << '\n'; > std::cout << "z parts:" << ' ' << x << ' ' << y << '\n'; > > I'm not sure if you believe this implies a call to get to decomponse as= =20 > rvalues, but it isn't. > It just copies the complex to a temporary, and then calls get on this=20 > temporary. > The z, x, y part is lvalue decomp. ..=20 > > z.real(3); > z.imag(4); > std::cout << "z =3D " << z << '\n'; > std::cout << "z parts:" << ' ' << x << ' ' << y << '\n'; > > std::complex w(1, 2); > std::cout << "w =3D " << w << '\n'; > auto& [p, q] =3D w; > > I'm not sure if you believe this implies a call to get to decomponse as= =20 > lvalues, but it isn't. > It just takes store a reference to the complex in a temporary, and then= =20 > calls get on this temporary reference. > The w, p, q part is rvalue decomp. =20 > > w.real(3); > w.imag(4); > std::cout << "w =3D " << w << '\n'; > std::cout << "w parts:" << ' ' << p << ' ' << q << '\n'; > > p =3D -5; > q =3D -6; > std::cout << "w =3D " << w << '\n'; > std::cout << "w parts:" << ' ' << p << ' ' << q << '\n'; > > return; > } > > int > main() > { > test_complex_decomp(); > return 0; > } > > > > ------------------- > z =3D (1,2) > z parts: 1 2 > z =3D (3,4) > z parts: 1 2 > w =3D (1,2) > w =3D (3,4) > w parts: 3 4 > w =3D (-5,-6) > w parts: -5 -6 > ------------------- > > The static cast, ugly as it is, is required to be valid by conforming=20 > implementations of complex. > > Are you talking of the reinterpret_cast? > Yes, reinterpret_cast. sorry. =20 > 29.5 Complex numbers [complex.numbers] p4, specifically 4.1-4.3. > This solution elegantly isolates user code from this wart. > > I believe that you need const/non const lvalue/rvalue decomposition, but= =20 > maybe I'm wrong. > > template > constexpr const RealTp&& > get(const std::complex&& z) > { > static_assert(_Int < 2, "index is out of bounds"); > return _Int =3D=3D 0 ? z.real() : z.imag(); > } > > Not sure about this one. I think it just might not be useful.=20 > > template > constexpr RealTp&& > get(std::complex&& z) > { > static_assert(_Int < 2, "index is out of bounds"); > return _Int =3D=3D 0 ? z.real() : z.imag(); > } > I think you're right here. std::array has at least this one. =20 > // Decompose complex as lvalues. > // Decompose complex as rvalues. > template > constexpr RealTp& > get(std::complex& z) > { > static_assert(_Int < 2, "index is out of bounds"); > auto w =3D reinterpret_cast(z); > return _Int =3D=3D 0 ? w[0] : w[1]; > } > > // Decompose complex as lvalues. > template > constexpr RealTp const& > get(const std::complex& z) > { > static_assert(_Int < 2, "index is out of bounds"); > auto w =3D reinterpret_cast(z); > return _Int =3D=3D 0 ? w[0] : w[1]; > } > > =20 Thank you for looking this over. Ed =20 > Vicente > =20 =20 --=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/5fc8b8b9-c0f6-4620-b54a-62acde6cb7f0%40isocpp.or= g. ------=_Part_1228_1846414457.1492200077635 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Friday, April 14, 2017 at 1:02:02 PM UTC-4, Vic= ente J. Botet Escriba wrote:
=20 =20 =20
Le 14/04/2017 =C3=A0 00:11, 3dw...@verizon.net a =C3=A9crit=C2=A0:
In many uses of std::complex
one wants to capture the real and imaginary parts in separate variables either to use them in subsequent calculations or to modify them individually.
There are many options:

These options reflect an over-encapsulation of std::complex, which everyone agrees is a struct with two floating point numbers, real part and imaginary part, in that order.
Attempting to use a decomposition declaration for a complex number is an error because of the pretension (ostensibly for C compatibility) the complex numbers are opaque.
Humm, it is not so opaque as you can get the representation as a c-array.

This means that we should already be able to apply structured binding using the cast

=C2=A0 =C2=A0 auto& [p, q] <= /span>=3D reinterpret_cast<Tp(&)[2]>(z);

This is c= ertainly legal now.=C2=A0 That's how I implement this.=C2=A0 It's j= ust fugly and obscure for users.


Nevertheles I agree with you that your proposal makes this cleaner and more explicit. Complex should be a ProductType.

The rvalue and lvalue decomposition of std::complex can be accomplished with a simple pure-library extension:
Provide a tuple interface to std::complex.

=C2=A0 // Tuple interface to class template complex. #define __cxx_lib_tuple_complex 2= 01705

=C2=A0 // Declare tuple_s= ize.
=C2=A0 template<typename RealTp>
=C2=A0 =C2=A0 class tuple_size;

=C2=A0 // Partial special= ization for std::complex.
=C2=A0 template<typename RealTp>
=C2=A0 =C2=A0 struct tuple_size<std::complex<RealTp>&= gt;
=C2=A0 =C2=A0 : public integral_constant<std::size_t, 2> { };

=C2=A0 // Declare tuple_e= lement.
=C2=A0 template<std::size_t _Int, typename RealTp>
=C2=A0 =C2=A0 class tuple_element;

=C2=A0 // Partial special= ization for std::complex.
=C2=A0 template<std::size_t _Int, typename RealTp>
=C2=A0 =C2=A0 struct tuple_element<<= span style=3D"color:#000">_Int, std::complex<= RealTp>>=
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 stat= ic_assert(_Int < 2= , "= ;index is out of bounds");<= /span>
=C2=A0 =C2=A0 =C2=A0 type= def Rea= lTp type;
=C2=A0 =C2=A0 };

=C2=A0 // Decompose compl= ex as rvalues.
=C2=A0 template<std::size_t _Int, typename RealTp>
=C2=A0 =C2=A0 constexpr const RealTp
=C2=A0 =C2=A0 get<= span style=3D"color:#660">(const std::complex<RealTp>&am= p; z)
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 stat= ic_assert(_Int < 2= , "= ;index is out of bounds");<= /span>
=C2=A0 =C2=A0 =C2=A0 retu= rn _Int =3D=3D 0 ? z.= real()<= span style=3D"color:#000"> : z.imag();
=C2=A0 =C2=A0 }

=C2=A0 // Decompose compl= ex as lvalues.
=C2=A0 template<std::size_t _Int, typename RealTp>
=C2=A0 =C2=A0 constexpr RealTp&
=C2=A0 =C2=A0 get<= span style=3D"color:#660">(std::complex<RealTp>& z)
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 stat= ic_assert(_Int < 2= , "= ;index is out of bounds");<= /span>
=C2=A0 =C2=A0 =C2=A0 auto= w =3D<= /span> reinter= pret_cast<RealTp(&)[2]>(z);
=C2=A0 =C2=A0 =C2=A0 retu= rn _Int =3D=3D 0 ? w[= 0] : w[1];
=C2=A0 =C2=A0 }


I believed that this reinterpret_cast was UB, but as you note below, it is defined by the standard.


Then we have the following behavior:

template<typename Tp>
=C2=A0 void
=C2=A0 test_complex_decomp()
=C2=A0 {
=C2=A0 =C2=A0 std::complex<Tp> z(= 1, 2);

=C2=A0 =C2=A0 auto= [x, y] =3D z;
=C2=A0 =C2=A0 std::cout <<= "= z =3D " << z << '\n';
=C2=A0 =C2=A0 std::cout <<= "= z parts:" << ' ' << x <= /span><<= ' ' << y << '\n';

I'm not sure if you believe this implies a call to get to decomponse as rvalues, but it isn't.
It just copies the complex to a temporary, and then calls get on this temporary.

Th= e z, x, y part is lvalue decomp.
.

=C2=A0 =C2=A0 z.real(3);
=C2=A0 =C2=A0 z.imag(4);
=C2=A0 =C2=A0 std::cout <<= "= z =3D " << z << '\n';
=C2=A0 =C2=A0 std::cout <<= "= z parts:" << ' ' << x <= /span><<= ' ' << y << '\n';

=C2=A0 =C2=A0 std::complex<Tp> w(= 1, 2);
=C2=A0 =C2=A0 std::cout <<= "= w =3D " << w << '\n';
=C2=A0 =C2=A0 auto= & <= span style=3D"color:#660">[p, q] =3D w;

I'm not sure if you believe this implies a call to get to decomponse as lvalues, but it isn't.
It just takes store a reference to the complex in a temporary, and then calls get on this temporary reference.
=

The w, p, q part is rvalue decomp.
=C2=A0

=C2=A0 =C2=A0 w.real(3);
=C2=A0 =C2=A0 w.imag(4);
=C2=A0 =C2=A0 std::cout <<= "= w =3D " << w << '\n';
=C2=A0 =C2=A0 std::cout <<= "= w parts:" << ' ' << p <= /span><<= ' ' << q << '\n';

=C2=A0 =C2=A0 p =3D -5;
=C2=A0 =C2=A0 q =3D -6;
=C2=A0 =C2=A0 std::cout <<= "= w =3D " << w << '\n';
=C2=A0 =C2=A0 std::cout <<= "= w parts:" << ' ' << p <= /span><<= ' ' << q << '\n';

=C2=A0 =C2=A0 return;
=C2=A0 }

int
main()
{
=C2=A0 test_complex_decomp<double>();
=C2=A0 return 0;
}



-------------------
z =3D (1,2)
z parts: 1 2
z =3D (3,4)
z parts: 1 2
w =3D (1,2)
w =3D (3,4)
w parts: 3 4
w =3D (-5,-6)
w parts: -5 -6
-------------------

The static cast, ugly as it is, is required to be valid by conforming implementations of complex.
Are you talking of the reinterpret_cast?
Yes, reinterpret_cast. sorry.
=C2=A0
29.5 Complex numbers [complex.numbers] p4, specifically 4.1-4.3.
This solution elegantly isolates user code from this wart.
I believe that you need const/non const lvalue/rvalue decomposition, but maybe I'm wrong.

=C2=A0 template<std::size_t _Int, typename RealTp>
=C2=A0 =C2=A0 constexpr const RealTp&&
=C2=A0 =C2=A0 get(const std::complex<RealTp<= span style=3D"color:#660">>&& = z)
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 static_asser= t(_Int = < 2,= "index i= s out of bounds");
=C2=A0 =C2=A0 =C2=A0 return _Int =3D=3D<= /span> 0 ? z.real() : z.imag();
=C2=A0 =C2=A0 }

Not sure about this one.= =C2=A0 I think it just might not be useful.

=C2= =A0 template<std::size_t _Int, typename RealTp>
=C2=A0 =C2=A0 constexpr RealTp&& =C2=A0 =C2=A0 get(std::complex<RealTp>&& z<= /span>)
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 static_a= ssert(_= Int < 2, "ind= ex is out of bounds");<= span style=3D"color:#000">
=C2=A0 =C2=A0 =C2=A0 return _Int =3D= =3D 0 ?= z.real() : z.imag();
=C2=A0 =C2=A0 }

I think you're right here.=C2=A0 std::array has at least this one.=
=C2=A0
=C2=A0 // Decompo= se complex as lvalues.
<= /div>
=C2=A0=C2=A0 // Decompose complex as rvalues.
=C2=A0 template<std::size_t _Int, typename RealTp>
=C2=A0 =C2=A0 constexpr RealTp&
=C2=A0 =C2=A0 get(std::complex<RealTp>& z)
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 static_asser= t(_Int = < 2,= "index i= s out of bounds");
=C2=A0 =C2=A0 =C2=A0 auto<= span style=3D"color:#000"> w =3D reinterpret_cas= t<Re= alTp(&)[2]>(z);
=C2=A0 =C2=A0 =C2=A0 return _Int =3D=3D<= /span> 0 ? w[0] : w[1];
=C2=A0 =C2=A0 }

=C2=A0 // Decompose complex as lvalues.
=C2=A0 template<std::size_t _Int, typename RealTp>
=C2=A0 =C2=A0 constexpr RealTp const&
=C2=A0 =C2=A0 get(const std::complex<RealTp<= span style=3D"color:#660">>& z)
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 static_asser= t(_Int = < 2,= "index i= s out of bounds");
=C2=A0 =C2=A0 =C2=A0 auto<= span style=3D"color:#000"> w =3D reinterpret_cas= t<Re= alTp const(&)[2]>(z);
=C2=A0 =C2=A0 =C2=A0 return _Int =3D=3D<= /span> 0 ? w[0] : w[1];
=C2=A0 =C2=A0 }

=C2=A0
Thank you = for looking this over.
Ed

=C2=A0
Vicente
=C2=A0
=C2=A0

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/5fc8b8b9-c0f6-4620-b54a-62acde6cb7f0= %40isocpp.org.
------=_Part_1228_1846414457.1492200077635-- ------=_Part_1227_1652640001.1492200077632-- .