220 11315 <81f95afc-7a67-45cd-950c-433528b2b8db@isocpp.org> 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: Fri, 13 Jun 2014 21:30:44 -0700 (PDT) Lines: 496 Approved: news@gmane.org Message-ID: <81f95afc-7a67-45cd-950c-433528b2b8db@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_470_4479249.1402720245054" X-Trace: ger.gmane.org 1402720257 29478 80.91.229.3 (14 Jun 2014 04:30:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Jun 2014 04:30:57 +0000 (UTC) Cc: lukaszme@microsoft.com, stl@exchange.microsoft.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCYZZ4E5WQCRB5U756OAKGQEACS7T2A@isocpp.org Sat Jun 14 06:30:49 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yk0-f200.google.com ([209.85.160.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Wvfc8-0007yF-EW for gclcip-std-proposals@m.gmane.org; Sat, 14 Jun 2014 06:30:48 +0200 Original-Received: by mail-yk0-f200.google.com with SMTP id 20sf8454572yks.11 for ; Fri, 13 Jun 2014 21:30:47 -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:cc: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=ImifYS5g9hdYdJ9+Giww+eaa5ahli6gY0R8qv2BlVgs=; b=UrRHavmpwmux8zo6pM1AZN0DhC/nOxjO0kweUiNtfIqauElLAAVtJJse+f870C62Q3 jSjAKRIWYnorL77Y65xZqKzViGNLtRiOZ21WoK/y+oqk+WEj74Y44CCJV9zQapp8c9aE vUpWFXD3mxnp32iS/hZ+ANZ8vgzP+f1Hw5CvJoL9Geyv4YjTdMy/jBnC9x+wmBDcvoSI uc+Aa/BGBDQUGpkqgIMJkueWefyPv1oTmBZobDwfPwCLv8ABjT7w2FrhlCkR9r7Q+j6b AAZf9sCE1D2CcfWSU++RxRoxkxH2hRC3MvpdQaEb9HwyM5mwNh5seI34lmtB/jE4jB+R b5jQ== X-Gm-Message-State: ALoCoQn9E7qbZHrnYuLNcl5XUrItHtsT+XNBmZlwdOt41vSf1ZS56dZacaWQbCfnCJudZpQFnni3 X-Received: by 10.58.187.68 with SMTP id fq4mr2357270vec.0.1402720247344; Fri, 13 Jun 2014 21:30:47 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.49.98 with SMTP id t2ls80967ign.26.gmail; Fri, 13 Jun 2014 21:30:46 -0700 (PDT) X-Received: by 10.51.17.34 with SMTP id gb2mr169822igd.4.1402720246631; Fri, 13 Jun 2014 21:30:46 -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:11315 Archived-At: ------=_Part_470_4479249.1402720245054 Content-Type: text/plain; charset=UTF-8 On Friday, June 13, 2014 5:54:21 PM UTC-7, Jeffrey Yasskin wrote: > > Thanks for the comments. Lukasz, FYI in case you're not on this list. > > On Fri, Jun 13, 2014 at 9:17 PM, Jeremy Maitin-Shepard > > wrote: > > C++ is sorely in need of a "vocabulary type" for representing pointer > > ranges. It is also sorely in need of a good, standard library for > > multidimensional arrays/containers/ranges. While the design space for a > > one-dimensional, unstrided array view is fairly limited, the design > space > > for a multidimensional array/container/range is very large. Finding the > > right design certainly involves numerous design iterations and very > > substantial user experience. While the proposed design in n3976 is a > very > > useful starting point, it would be premature to standardize it at this > > point, as it is far from comprehensive and it is difficult to know how > well > > the proposed interface could be extended to provide a larger set of > > functionality on par with the facilities available in many other > languages. > > According to N3851, > http://msdn.microsoft.com/en-us/library/vstudio/hh305260(v=vs.110).aspx > > seems to be that user experience. We'll also have a chance to get more > experience while this is in a TS before being standardized. > I saw that, but the fact that it is part of AMP suggests that the focus is a bit more specialized than a general multidimensional array. > > Some particular issues with the proposed design include: > > > > - No iterators are provided for array_view or strided_array_view, a > clear > > omission in the interface. For a multidimensional array, there are two > > obvious types of iteration that may be desired: > > 1. iterating over just the first dimension; > > 2. iterating over a flat view of all of the elements. For a strided > > array, iterating over a flat view cannot be done efficiently without > > segmented/hierarchical iterators. > > Which of these should be the default (i.e. provided through begin() > and > > end() rather than through some adaptor) is not clear, > > From the Zen of Python, "In the face of ambiguity, refuse the > temptation to guess." > > That's true, but no adaptors to provide the functionality unambiguously are provided either. For the particular case of a one-dimensional array, there is no ambiguity, and not being able to easily use array_view with standard algorithms or range-based for is a serious usability issue. This will only become worse if/when standard algorithm overloads that take ranges rather than iterator pairs are added. > - No data() access member for strided_array_view. This is presumably > > omitted because the memory is non-contiguous, but given that > > strided_array_view is a thin wrapper, there has to be a convenient way > to > > get at the underlying memory. > > Why "has to"? > Because the user might want to convert the array to another representation for use by another piece of code/library, e.g. FFTW or Eigen, CUDA memcpy, etc. Under the proposed interface, for a 3-dimensional stided array view, you have to use &arr[0][0][0]. This is even worse than having to do &vec[0] for std::vector, since the same expression cannot be used independent of the dimensionality. > > > Given the definition of Viewable, the use of > > the name data() might be problematic as it would allow the incorrect > (albeit > > explicit) conversion from strided_array_view to array_view. Possibly > > Viewable should be traits-based rather than based only on the presence > of > > data() and size(). > > The downside of traits, of course, is that we'd burden users with > marking their types. If nearly all existing contiguous types expose > data()/size(), the library can save people work by using them. > That's a valid point. > > > - Slicing is limited: it is not possible to take a slice in a dimension > > other than the first. > > I think that's called "section()". > Well, that takes a "section" but does not reduce the dimensionality like "slice". For instance, suppose I have a two-dimensional 20x10 array arr and want to do the equivalent of the numpy: arr[:,5] and obtain a 1-dimensional strided_array_view of length 20. Certainly there is a large design space for general subscripting and it almost certainly requires a fair amount of template metaprogramming, but this is very useful functionality. > > - operator++ and operator-- on index seem very questionable. The > semantics > > are rather arbitrary and not that likely to be useful except for a > single > > dimension anyway. > > They're marked with "Requires: Rank == 1." This should be more like > "Ill-formed unless ...", but the goal is there. > Sorry, I missed that requirement. No problem there then. > > > - It is not clear whether it is really useful to have bounds and index > be > > separate types (though should probably at least be explicitly > convertible to > > each other). > > It adds a bit of type safety. Adding two bounds, for instance, doesn't > make a lot of sense. > I agree that type safety is in principle useful, but it is impossible to predict what relationships might hold in any given program, and so there is the question of whether the safety it adds is worth the cost of having to explicitly work around it in the cases that it is too restrictive. Certainly if they are separate types there needs to be a way to (explicitly) convert. Right now the only way to convert is to write a manual loop and use operator[], or possibly use operator[] to obtain pointers and then call memcpy or std::copy. As a specific example, consider if we want to compute the bounds of a valid convolution if we have an array x and a filter k. The bounds of the result are: x.bounds - k.bounds + 1. None of the arithmetic operators defined in the proposal help me with that; I'd just have to write a loop. Even if the arithmetic operators weren't limited by the bounds/index distinction, there would still be no way to create a constant-valued vector, i.e. to handle the constant 1. Another related issue I didn't notice before: the only way to construct an index or bounds type is from an initializer_list. There is no (explicit) conversion from std::array, for instance. It is quite likely that an index or bounds value would be computed by some other code, that may use a different representation. > > > Furthermore, bounds and index essentially represent a > > fixed-size discrete vector type, i.e. an augmented interface for > std::array. > > Arguably the interface of std::array should just be extended to add > > component-wise operators instead. Also, a much more comprehensive set > of > > component-wise operations should be provided. A statically-sized vector > > type is sorely needed in C++, but it does not make sense to standardize > > these limited, single-purposes types when they could be, and should be, > much > > more general. > > We don't necessarily want to go for the most general possible type all at > once. > Certainly there is a large design space, but that is a reason to be cautious about standardizing anything. Given the long turn around time for revisions to C++, it doesn't make sense to standardize a partial solution; better to work out a good, complete interface outside the standard. Given that there is no standard fixed-length vector, users will be tempted to use index as one, but will quickly find it to be lacking in important functionality. > > Other omissions from index and bounds include: > > 1. no data() access to the components > > 2. no iterators over components for index or bound > > How are those related to indexing? > Maybe I want to print out the index, by iterating over the components. Maybe I want to convert the index to/from another representation using the raw array representation. An index is just a value in the program, and there is no way of knowing what operations the user may want to perform on it. The philosophy of C++ is to not get in the user's way. > > > 3. the iterators for bounds iterate over positions, but are inefficient > > without segment/hierarchical iterators. > > Show us your measurements when you make an efficiency claim. > Alright, fair enough. Still, it would be nice to be able to generate code equivalent to N nested for loops for an N dimensional bounds. > > This position iteration is clearly > > useful but the facility at present is very limited: it should likely be > > presented as a multidimensional range itself, and support a non-zero > origin. > > What's the use case? This is useful in conjunction with a multdimensional, multiple range for_each. Suppose we have two multidimensional arrays x_array and y_array with the same bounds. We then might want: for_each(x_array, y_array, [&](auto &x, auto &y) { x += y; }); However, we might also want: for_each(x_array, y_array, x_array.bounds(), [&](auto &x, auto &y, auto pos) { if (x != y) std::cout << "mismatch at position " << pos << std::endl; }); This could also be further improved by the use of macros or a language extension that allows x and x_array, y and y_array, x_array.bounds() and pos to be syntactically related. -- --- 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_470_4479249.1402720245054 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Friday, June 13, 2014 5:54:21 PM UTC-7, Jeffrey= Yasskin wrote:
Thanks for the = comments. Lukasz, FYI in case you're not on this list.

On Fri, Jun 13, 2014 at 9:17 PM, Jeremy Maitin-Shepard
<jer...@jeremyms.com> wr= ote:
> C++ is sorely in need of a "vocabulary type" for representing poin= ter
> ranges.  It is also sorely in need of a good, standard librar= y for
> multidimensional arrays/containers/ranges.  While the design = space for a
> one-dimensional, unstrided array view is fairly limited, the desig= n space
> for a multidimensional array/container/range is very large.  = Finding the
> right design certainly involves numerous design iterations and ver= y
> substantial user experience.  While the proposed design in n3= 976 is a very
> useful starting point, it would be premature to standardize it at = this
> point, as it is far from comprehensive and it is difficult to know= how well
> the proposed interface could be extended to provide a larger set o= f
> functionality on par with the facilities available in many other l= anguages.

According to N3851,
http://m= sdn.microsoft.com/en-us/library/vstudio/hh305260(v=3Dvs.110).aspx=
seems to be that user experience. We'll also have a chance to get more
experience while this is in a TS before being standardized.

I saw that, but the fact that it is part of AMP s= uggests that the focus is a bit more specialized than a general multidimens= ional array.


> Some particular issues with the proposed design include:
>
> - No iterators are provided for array_view or strided_array_view, = a clear
> omission in the interface.  For a multidimensional array, the= re are two
> obvious types of iteration that may be desired:
>   1. iterating over just the first dimension;
>   2. iterating over a flat view of all of the elements.  = ;For a strided
> array, iterating over a flat view cannot be done efficiently witho= ut
> segmented/hierarchical iterators.
>   Which of these should be the default (i.e. provided through= begin() and
> end() rather than through some adaptor) is not clear,

From the Zen of Python, "In the face of ambiguity, refuse the
temptation to guess."

That's true, but no adaptors to provide the functiona= lity unambiguously are provided either.  For the particular case of a = one-dimensional array, there is no ambiguity, and not being able to easily = use array_view with standard algorithms or range-based for is a serious usa= bility issue.  This will only become worse if/when standard algorithm = overloads that take ranges rather than iterator pairs are added.

> - No data() access mem= ber for strided_array_view.  This is presumably
> omitted because the memory is non-contiguous, but given that
> strided_array_view is a thin wrapper, there has to be a convenient= way to
> get at the underlying memory.

Why "has to"?

Because the user might want to convert the array = to another representation for use by another piece of code/library, e.g. FF= TW or Eigen, CUDA memcpy, etc.  Under the proposed interface, for a 3-= dimensional stided array view, you have to use &arr[0][0][0].  Thi= s is even worse than having to do &vec[0] for std::vector, since the sa= me expression cannot be used independent of the dimensionality.
 

>  Given the definition of Viewable, the use of
> the name data() might be problematic as it would allow the incorre= ct (albeit
> explicit) conversion from strided_array_view to array_view.  = Possibly
> Viewable should be traits-based rather than based only on the pres= ence of
> data() and size().

The downside of traits, of course, is that we'd burden users with
marking their types. If nearly all existing contiguous types expose
data()/size(), the library can save people work by using them.

That's a valid point.
 

> - Slicing is limited: it is not possible to take a slice in a dime= nsion
> other than the first.

I think that's called "section()".

Well, that takes a "section" but does not reduce = the dimensionality like "slice".  For instance, suppose I have a two-d= imensional 20x10 array arr and want to do the equivalent of the numpy:
<= br>arr[:,5]
 
and obtain a 1-dimensional strided_array_view of l= ength 20.

Certainly there is a large design space for general subscr= ipting and it almost certainly requires a fair amount of template metaprogr= amming, but this is very useful functionality.


> - operator++ and operator-- on index seem very questionable.  = ;The semantics
> are rather arbitrary and not that likely to be useful except for a= single
> dimension anyway.

They're marked with "Requires: Rank =3D=3D 1." This should be more like
"Ill-formed unless ...", but the goal is there.
Sorry, I missed that requirement.  No problem th= ere then.
 

> - It is not clear whether it is really useful to have bounds and i= ndex be
> separate types (though should probably at least be explicitly conv= ertible to
> each other).

It adds a bit of type safety. Adding two bounds, for instance, doesn't
make a lot of sense.
I agree that type safety is in principle useful, but = it is impossible to predict what relationships might hold in any given prog= ram, and so there is the question of whether the safety it adds is worth th= e cost of having to explicitly work around it in the cases that it is too r= estrictive.  Certainly if they are separate types there needs to be a = way to (explicitly) convert.  Right now the only way to convert is to = write a manual loop and use operator[], or possibly use operator[] to obtai= n pointers and then call memcpy or std::copy.

As a specific example,= consider if we want to compute the bounds of a valid convolution if we hav= e an array x and a filter k.  The bounds of the result are: x.bounds -= k.bounds + 1.  None of the arithmetic operators defined in the propos= al help me with that; I'd just have to write a loop.  Even if the arit= hmetic operators weren't limited by the bounds/index distinction, there wou= ld still be no way to create a constant-valued vector, i.e. to handle the c= onstant 1.

Another related issue I didn't notice before: the only wa= y to construct an index or bounds type is from an initializer_list.  T= here is no (explicit) conversion from std::array, for instance.  It is= quite likely that an index or bounds value would be computed by some other= code, that may use a different representation.

> Furthermore, bounds and index essentially represent a
> fixed-size discrete vector type, i.e. an augmented interface for s= td::array.
> Arguably the interface of std::array should just be extended to ad= d
> component-wise operators instead.  Also, a much more comprehe= nsive set of
> component-wise operations should be provided.  A statically-s= ized vector
> type is sorely needed in C++, but it does not make sense to standa= rdize
> these limited, single-purposes types when they could be, and shoul= d be, much
> more general.

We don't necessarily want to go for the most general possible type all = at once.

Certainly there is a large design space, but that= is a reason to be cautious about standardizing anything.  Given the l= ong turn around time for revisions to C++, it doesn't make sense to standar= dize a partial solution; better to work out a good, complete interface outs= ide the standard.  Given that there is no standard fixed-length vector= , users will be tempted to use index as one, but will quickly find it to be= lacking in important functionality.
 
> Other omissions from index and bounds= include:
>  1. no data() access to the components
>  2. no iterators over components for index or bound

How are those related to indexing?

Maybe I want to print out the index, by iterating= over the components.  Maybe I want to convert the index to/from anoth= er representation using the raw array representation.  An index is jus= t a value in the program, and there is no way of knowing what operations th= e user may want to perform on it.  The philosophy of C++ is to not get= in the user's way.
 

>  3. the iterators for bounds iterate over positions, but are = inefficient
> without segment/hierarchical iterators.

Show us your measurements when you make an efficiency claim.

Alright, fair enough.  Still, it would be ni= ce to be able to generate code equivalent to N nested for loops for an N di= mensional bounds.

 
> This position iteration is clearly
> useful but the facility at present is very limited: it should like= ly be
> presented as a multidimensional range itself, and support a non-ze= ro origin.

What's the use case?

This is useful in conjunction= with a multdimensional, multiple range for_each.  Suppose we have two= multidimensional arrays x_array and y_array with the same bounds.  We= then might want:
for_each(x_array, y_array, [&](auto &x, auto &= amp;y) { x +=3D y; });

However, we might also want:

for_each(= x_array, y_array, x_array.bounds(), [&](auto &x, auto &y, auto = pos) {
  if (x !=3D y) std::cout << "mismatch at position " &= lt;< pos << std::endl;
});
 
This could also be furt= her improved by the use of macros or a language extension that allows x and= x_array, y and y_array, x_array.bounds() and pos to be syntactically relat= ed.

--

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