220 11326 article Path: news.gmane.org!not-for-mail From: Jeremy Maitin-Shepard Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Comments on n3976 (array_view) Date: Sat, 14 Jun 2014 11:11:06 -0700 (PDT) Lines: 193 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_928_22262662.1402769466742" X-Trace: ger.gmane.org 1402769480 9902 80.91.229.3 (14 Jun 2014 18:11:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Jun 2014 18:11:20 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCYZZ4E5WQCRBPVA6KOAKGQEN2K2G7I@isocpp.org Sat Jun 14 20:11:12 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f200.google.com ([209.85.213.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WvsQ4-0005CL-Ab for gclcip-std-proposals@m.gmane.org; Sat, 14 Jun 2014 20:11:12 +0200 Original-Received: by mail-ig0-f200.google.com with SMTP id l13sf5940272iga.3 for ; Sat, 14 Jun 2014 11:11:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=w8oBAXxF2W963CVMS9+kYEfBmtIhI+5uOcYyuNTgfc0=; b=Lg4Zqn6KdXGAlgEbKZXl+pH1IDnFqeeIhTf92oKOuTq8iDMu7pVpZe7D13dZmQ8voK adq0pWDfU5ru4qQ+YR1BNmwkWfHyOuuT/9fST11KLkFgZ+GSoEYiethbdYZQh48rYziO xz7tmTGZr2010BkRe6+My3souBBC5eyobxvztVgRdlfFuoAniBd6URX/GRl6In01sWOO AebdzQ3ln2W0coy85SQvJ4vyWhAowBHfYwb8vXigBzhJrafM+pW/DZbbOLft49UAjJ3r w8peVxnzDoteL5ErnQgP2HmEmAnfk1pDAfQjH0weA53XWuMBz6qH9wx8lofQfrNgnxOb GcUA== X-Gm-Message-State: ALoCoQllszyEmx3FLd7cST/FYsbbk9M/z7CXQD26w+bHRDVzzV9ap6WCH4QZcHwKk2f7VxC4s/vL X-Received: by 10.42.249.207 with SMTP id ml15mr2020582icb.21.1402769471206; Sat, 14 Jun 2014 11:11:11 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.85.39 with SMTP id e7ls266208igz.14.canary; Sat, 14 Jun 2014 11:11:10 -0700 (PDT) X-Received: by 10.50.61.145 with SMTP id p17mr232208igr.16.1402769470529; Sat, 14 Jun 2014 11:11:10 -0700 (PDT) In-Reply-To: X-Original-Sender: jeremy@jeremyms.com 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:11326 Archived-At: ------=_Part_928_22262662.1402769466742 Content-Type: text/plain; charset=UTF-8 On Saturday, June 14, 2014 3:35:35 AM UTC-7, Bengt Gustafsson wrote: > > I would like array_view to cater for the case that one or more dimensions > is fixed size. This can improve performance by a lot and also provies > additional documentation value for functions requiring its data to actually > have a certain bound in a particular dimension. I think that the bounds > representation used by Eigen could work for array_view too: > > static const size_t var_dim = -1; > template class array_view; > > The interpretation of this being that for a n dimensional array_view you > mention n sizes as template parameters, any of which may be the marker > value var_dim which indicates a variable dimension and activates a > specialization of the template. > I agree that it is certainly useful to be able to specify information about sizes and strides (as you describe later in the message) at compile time. Potentially it is also useful to specify information about alignment, or the fact that a size or stride is a multiple of some compile time constant, etc. At least if it is the last dimension that is statically sized, you can work around it by just making it array_view,1>, and you could provide convenient ways to convert to and from array_view. This is also the case that may be the most useful in terms of optimization. There is no problem in principle with allowing all of this compile-time specification, it is just a matter of figuring out the right model for representing all of it, and figure out a suitable syntax for specifying it all. The best way to do that is to implement it as a library and see how things work out. It might not (probably won't) be possible to stuff all of this functionality into a single template argument list that is also convenient for the simple cases, but that isn't a problem given that we have template aliases. It is, for instance, more convenient to be able to type MultiDimensionalArray rather than MultiDimensionalArray. I have suggested this system as an extension of the current array<> > template to n dimensions previously, see thread > https://groups.google.com/a/isocpp.org/forum/#!topicsearch/bengt$20gustafsson/std-proposals/hW2QAvmboqU. > As easily seen the current one dimensional, fixed size case fits nicely > under this umbrella. The idea was that the variable size specializations of > array<> would use a new VLA feature whenever that enters C++. but use the > heap in the meantime. > I think something like that should wait until runtime-sized structs are supported. Otherwise the heap allocation makes it non-POD. > The lack of a (mathematical) vector type with suitable operations could > possibly be solved by applying the above var_dim possibility to valarray: > > template class valarray; > > template class valarray; // The current valarray > is the specialization for var_dim. > > valarray provides memberwise operations as well as operations to one > scalar T already. More math stuff can be added as functions of course: dot > product, length or whatever. > I don't know if changing the template argument list of valarray would pose compatibility problems. There is also the fact that valarray is allowed to use expression templates, which is probably undesirable for fixed-size types. In general a fixed-size valarray is a very useful addition, though; it would probably get used more than the current variable-sized valarray, which as far as I understand is hardly ever used. Note that the valarray could be multidimensional as well. > I would also prefer if there were specializations for 2 and 3 dimensions > where the elements are named x, y and z (for instance using a union with > the array). > -- --- 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 email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_928_22262662.1402769466742 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Saturday, June 14, 2014 3:35:35 AM UTC-7, Bengt Gustafs= son wrote:
I would like array_view to cater for the c= ase that one or more dimensions is fixed size. This can improve performance= by a lot and also provies additional documentation value for functions req= uiring its data to actually have a certain bound in a particular dimension.= I  think that the bounds representation used by Eigen could work for = array_view too:

static const size_t var_dim =3D -1;
template<ty= pename T, size_t... Ss> class array_view;

The i= nterpretation of this being that for a n dimensional array_view you mention= n sizes as template parameters, any of which may be the marker value var_d= im which indicates a variable dimension and activates a specialization of t= he template.

I agree that it is certainly = useful to be able to specify information about sizes and strides (as you de= scribe later in the message) at compile time.  Potentially it is also = useful to specify information about alignment, or the fact that a size or s= tride is a multiple of some compile time constant, etc.

At least if = it is the last dimension that is statically sized, you can=20 work around it by just making it=20 array_view<std::array<T,X>,1>, and you could provide=20 convenient ways to convert to and from array_view<T,2>.  This is= =20 also the case that may be the most useful in terms of optimization.

= There is no problem in principle with allowing all of this compile-time=20 specification, it is just a matter of figuring out the right model for=20 representing all of it, and figure out a suitable syntax for specifying=20 it all.  The best way to do that is to implement it as a library and s= ee how things work out.

It might not (probably won't) be possible=20 to stuff all of this functionality into a single template argument list=20 that is also convenient for the simple cases, but that isn't a problem=20 given that we have template aliases.  It is, for instance, more=20 convenient to be able to type MultiDimensionalArray<int,3> rather=20 than MultiDimensionalArray<int,-1,-1,-1>.


I have = suggested this system as an extension of the current array<> template= to n dimensions previously, see thread https://groups.google.com/a/isocpp.org/forum/#!topi= csearch/bengt$20gustafsson/std-proposals/hW2QAvmboqU. As easi= ly seen the current one dimensional, fixed size case fits nicely under this= umbrella. The idea was that the variable size specializations of array<= > would use a new VLA feature whenever that enters C++. but use the heap= in the meantime.

I think something like t= hat should wait until runtime-sized structs are=20 supported.  Otherwise the heap allocation makes it non-POD.
=
 
The lack of a (mathematical) vector type with suitable operations = could possibly be solved by applying the above var_dim possibility to valar= ray:

template<typename T, size_t Sz> class v= alarray;

template<typename T> class valarray= <T. var_dim>;  // The current valarray is the specialization for= var_dim.

valarray provides memberwise operations = as well as operations to one scalar T already. More math stuff can be added= as functions of course: dot product, length or whatever.

I don't know if changing the template argument list of vala= rray would pose compatibility problems.  There is also the fact that v= alarray is allowed to use expression templates, which is probably undesirab= le for fixed-size types.  In general a fixed-size valarray is a very u= seful addition, though; it would probably get used more than the current va= riable-sized valarray, which as far as I understand is hardly ever used.&nb= sp; Note that the valarray could be multidimensional as well.

 
I would also prefer if there were specializations for 2= and 3 dimensions where the elements are named x, y and z (for instance usi= ng a union with the array).

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_928_22262662.1402769466742-- .