220 11336 <1e4d9cef-65a7-4651-a04d-51524063ce06@isocpp.org> article Path: news.gmane.org!not-for-mail From: Bengt Gustafsson Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Comments on n3976 (array_view) Date: Sat, 14 Jun 2014 12:43:33 -0700 (PDT) Lines: 321 Approved: news@gmane.org Message-ID: <1e4d9cef-65a7-4651-a04d-51524063ce06@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_560_8925170.1402775013840" X-Trace: ger.gmane.org 1402775024 6947 80.91.229.3 (14 Jun 2014 19:43:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Jun 2014 19:43:44 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCRIRSPDTQIRBZWL6KOAKGQEEXXWKCA@isocpp.org Sat Jun 14 21:43:37 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f70.google.com ([209.85.220.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WvtrU-00005U-Ep for gclcip-std-proposals@m.gmane.org; Sat, 14 Jun 2014 21:43:36 +0200 Original-Received: by mail-pa0-f70.google.com with SMTP id lj1sf15045314pab.9 for ; Sat, 14 Jun 2014 12:43:35 -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=EmqugQgefMxa5IIpJsEerS/mGGAu/MQfBLpu8VVxjy4=; b=HDxKMZCK82R+y7QEsIjED1BcMXCJRKtR+FiNrcDW8Zr+0DyAoU6AK+W3DuGC9tj7iy laLbio6zEg5vx6aS+ae1HxYqaH5YNz0XD5bbxiHWRRkHhKOCmnqPW1aGBZUm88opLZ4Y DnMoEYXvPf0Bm7oYEBw+XGbnOwI7TPjhozOtDfJ67OqZPmcm30b9jcQqmTbp1wGN7kEY 4PLWghlR1iMnzdP4X5d1nESKIdEQ8el3eDDSF4TWzIK7XCacLwJXA77oDrq7jtJBcnD2 QQLxVETCofigxixLjjGbInezk+LXgc/xMEiGRH+hy5JxXKtwH+blsdBpJXTt9hiwv0xg kXxA== X-Gm-Message-State: ALoCoQmiQrxckwmdygVE1BLZz4dEnSI7tofFPJEWcMyDtYJ1wdD4S6+rfVapIE/SvV3t8+XVuc3C X-Received: by 10.66.66.35 with SMTP id c3mr439165pat.7.1402775015394; Sat, 14 Jun 2014 12:43:35 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.49.130 with SMTP id q2ls4046263qga.91.gmail; Sat, 14 Jun 2014 12:43:34 -0700 (PDT) X-Received: by 10.140.92.77 with SMTP id a71mr174101qge.0.1402775014423; Sat, 14 Jun 2014 12:43:34 -0700 (PDT) In-Reply-To: X-Original-Sender: bengt.gustafsson@beamways.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:11336 Archived-At: ------=_Part_560_8925170.1402775013840 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Den l=C3=B6rdagen den 14:e juni 2014 kl. 20:11:07 UTC+2 skrev Jeremy=20 Maitin-Shepard: > > 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 dimension= s=20 >> is fixed size. This can improve performance by a lot and also provies=20 >> additional documentation value for functions requiring its data to actua= lly=20 >> have a certain bound in a particular dimension. I think that the bounds= =20 >> representation used by Eigen could work for array_view too: >> >> static const size_t var_dim =3D -1; >> template class array_view; >> >> The interpretation of this being that for a n dimensional array_view you= =20 >> mention n sizes as template parameters, any of which may be the marker= =20 >> value var_dim which indicates a variable dimension and activates a=20 >> specialization of the template. >> > > I agree that it is certainly useful to be able to specify information=20 > about sizes and strides (as you describe later in the message) at compile= =20 > time. Potentially it is also useful to specify information about=20 > alignment, or the fact that a size or stride is a multiple of some compil= e=20 > 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 array_view,1>, and you= =20 > could provide convenient ways to convert to and from array_view. Th= is=20 > 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= =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 i= t=20 > all. The best way to do that is to implement it as a library and see how= =20 > things work out. > > It might not (probably won't) be possible to stuff all of this=20 > functionality into a single template argument list that is also convenien= t=20 > for the simple cases, but that isn't a problem given that we have templat= e=20 > aliases. It is, for instance, more convenient to be able to type=20 > MultiDimensionalArray rather than=20 > MultiDimensionalArray. > Yes that could be a good idea, again, however, we need to worry about=20 namespace cluttering and for programmers to be able to remember it all. As= =20 a detail: Do you see a simple way to actually write the template alias you= =20 suggest? I see that it is possible using a recursive variadic template=20 helper but is there a simpler way? =20 > > > I have suggested this system as an extension of the current array<>=20 >> template to n dimensions previously, see thread=20 >> https://groups.google.com/a/isocpp.org/forum/#!topicsearch/bengt$20gusta= fsson/std-proposals/hW2QAvmboqU.=20 >> As easily seen the current one dimensional, fixed size case fits nicely= =20 >> under this umbrella. The idea was that the variable size specializations= of=20 >> array<> would use a new VLA feature whenever that enters C++. but use th= e=20 >> heap in the meantime. >> > > I think something like that should wait until runtime-sized structs are= =20 > supported. Otherwise the heap allocation makes it non-POD.=20 > If you mean structs with VLAs in them that is envisioned in the current=20 suggestions such as N4025 and my own reply to this (search this forum for= =20 N4025 and you will find it as a (long) commentary). =20 > =20 > >> The lack of a (mathematical) vector type with suitable operations could= =20 >> possibly be solved by applying the above var_dim possibility to valarray= : >> >> template class valarray; >> >> template class valarray; // The current valarra= y=20 >> is the specialization for var_dim. >> >> valarray provides memberwise operations as well as operations to one=20 >> scalar T already. More math stuff can be added as functions of course: d= ot=20 >> product, length or whatever. >> > > I don't know if changing the template argument list of valarray would pos= e=20 > compatibility problems. =20 > Yes I think it may be a breaking change if valarray is used as the template= =20 template argument of something declared like this: template class V> struct my_stuct; But I am not really certain whether a valarray=20 is allowed (given the default value) or not. I suspect it is not... Lets=20 see, a quick test on VS2013 cries out: error C3201: the template parameter= =20 list for class template 'valarray' does not match the template parameter=20 list for template parameter 'V' Well, we are working on the standard so it would at least theoretically=20 possible to make a core change simultaneously to allow this. I checked also= =20 whether the corresponding thing is allowed for function pointer but it is= =20 not. On the other hand class templates can't be overloaded in contrast with= =20 functions. =20 > There is also the fact that valarray is allowed to use expression=20 > templates, which is probably undesirable for fixed-size types. In genera= l=20 > a fixed-size valarray is a very useful addition, though; it would probabl= y=20 > get used more than the current variable-sized valarray, which as far as I= =20 > understand is hardly ever used. Note that the valarray could be=20 > multidimensional as well. > > =20 > I would not be opposed to implementing valarray's operators for array<> and= =20 make valarray an alias of array . In fact bounds and indices in= =20 my suggested multi-dimensional array are themselves array. I agree that it is painful to have different types for bounds and indices,= =20 and I have tried in an (in house) image processing library for the last 15= =20 years. It happens far more often than one would think that arithmetic is=20 done like you explain, such as adding the kernel and image size etc. --=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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. ------=_Part_560_8925170.1402775013840 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Den l=C3=B6rdagen den 14:e juni 2014 kl. 20:11:07 = UTC+2 skrev Jeremy Maitin-Shepard:
On Saturday, June 14, 2014 3:35:35 AM UTC-7, Bengt G= ustafsson wrote:
I would like array_view to cater for the = case that one or more dimensions is fixed size. This can improve performanc= e by a lot and also provies additional documentation value for functions re= quiring 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<t= ypename T, size_t... Ss> class array_view;

The = interpretation of this being that for a n dimensional array_view you mentio= n 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 d= escribe 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=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>.

Yes that could be a good idea, again, however, we= need to worry about namespace cluttering and for programmers to be able to= remember it all. As a detail: Do you see a simple way to actually write th= e template alias you suggest? I see that it is possible using a recursive v= ariadic template helper but= is there a simpler way?
 


I have suggested = this system as an extension of the current array<> template to n dime= nsions previously, see thread https://groups.google.com/a/isocpp.org/forum/#!topicsearch/be= ngt$20gustafsson/std-proposals/hW2QAvmboqU. As easily seen th= e 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 me= antime.

I think something like that should= wait until runtime-sized structs are=20 supported.  Otherwise the heap allocation makes it non-POD.
=
If you mean structs with VLAs in them that is envis= ioned in the current suggestions such as N4025 and my own reply to this (se= arch this forum for N4025 and you will find it as a (long) commentary).
 
 
The lack of a (mathematical) vector type with suitab= le operations could possibly be solved by applying the above var_dim possib= ility to valarray:

template<typename T, size_t = Sz> class valarray;

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

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

I don't know if changing the template argumen= t list of valarray would pose compatibility problems. 

Yes I think it may be a breaking change if va= larray is used as the template template argument of something declared like= this:

template<template<typename> class = V> struct my_stuct;

But I am not really certain= whether a valarray<typename T, size_t Sz =3D -1> is allowed (given t= he default value) or not. I suspect it is not... Lets see, a quick test on = VS2013 cries out: error C3201: the template parameter list for class t= emplate 'valarray' does not match the template parameter list for template = parameter 'V'

Well, we are working on the standard= so it would at least theoretically possible to make a core change simultan= eously to allow this. I checked also whether the corresponding thing is all= owed for function pointer but it is not. On the other hand class templates = can't be overloaded in contrast with functions.

&n= bsp;
There is also the fact that valarray is allowed to use expression templat= es, which is probably undesirable for fixed-size types.  In general a = fixed-size valarray is a very useful addition, though; it would probably ge= t used more than the current variable-sized valarray, which as far as I und= erstand is hardly ever used.  Note that the valarray could be multidim= ensional as well.

 
I w= ould not be opposed to implementing valarray's operators for array<> = and make valarray<T> an alias of array<T, -1> . In fact bounds = and indices in my suggested multi-dimensional array are themselves array<= ;size_t, RANK>.

I agree that it is painful to h= ave different types for bounds and indices, and I have tried in an (in hous= e) image processing library for the last 15 years. It happens far more ofte= n than one would think that arithmetic is done like you explain, such as ad= ding the kernel and image size etc.


--

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