220 9135 article Path: news.gmane.org!not-for-mail From: Jesse Perla Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: N3851, the array_view specification: notes and use cases for scientific computing Date: Wed, 5 Feb 2014 16:24:02 -0800 (PST) Lines: 553 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_7155_10483635.1391646242555" X-Trace: ger.gmane.org 1391646238 14512 80.91.229.3 (6 Feb 2014 00:23:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Feb 2014 00:23:58 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDPLLXOEXEORBJFMZOLQKGQEEAXNKIQ@isocpp.org Thu Feb 06 01:24:07 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oa0-f72.google.com ([209.85.219.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WBClC-0001tU-59 for gclcip-std-proposals@m.gmane.org; Thu, 06 Feb 2014 01:24:06 +0100 Original-Received: by mail-oa0-f72.google.com with SMTP id i4sf6313627oah.11 for ; Wed, 05 Feb 2014 16:24:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=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=UyIsT9R+Q4RxHvU6WwiOcfmwJwsH5ypcv0SljL1sfPI=; b=e51DIg+g6y0yBufTkXANHgipD8rDCU+/rYUgV2o68pkKnCm44bivskS0qFe8I/xLDw txCORuoaZdtXlqqmkvDSE2M5+jJvBISXraTVYz+iEwisQhrgIVYRE+KLCuV09zBnLZJo CE/w0hWky5HLNSOkJjzMH4kF28D38jl9oH3pq6vIunV3q6r78MxeSpAO3Y8nhNhkNZp6 +YPlJHYkSKvjggYLUILMySaMY5OrmooSupK4fioXDFQeNVSkDSoIV+Y9VgKy9vGPVV/W 8JazcDr0eADTaOkCK9TCDiD2MZLwtH2s1n+weE6ykQTQlG8ati5/TdeFfLXtm1qsweF9 ipJQ== 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=UyIsT9R+Q4RxHvU6WwiOcfmwJwsH5ypcv0SljL1sfPI=; b=h8+dQz5a3VMeNpeIzK8u2kx967iSSrUjQH2iEDLgvWkkHoXQ4GCCT4llfeSorHEmEq MfF4XogTvfQ9F86nxHTOHiPEYCFN/yt3qBXJcttUx3zSvBB8pNKSR1vUvfGFv7hhPXgz LItKRNxEzL7W1Zi2kv8kijGjpV6a1kKlf0nRJ9Ovrhuon/VI3rYxhvG4AXgilhoOlz2M BwR6aDyMn8XDfMYa34eWYt3+v/19nM2AHG/dKJKZfh+lglNs2V8S2xwIhXHE5jCrvIuA nL/WvIgai8YEFG4qOH3bbPxDtPzebJW9G6xtNGwajvP8kIpQz7n4to1fC778QjaUTa1W 9yIg== X-Gm-Message-State: ALoCoQlhkjENZo7MiCcGrrRPUoGQIT6XL2t7slHLPHlhHWq/dUtsVLIjTXpOJfOq91I0uoTmZfuN X-Received: by 10.182.126.137 with SMTP id my9mr2075472obb.13.1391646245132; Wed, 05 Feb 2014 16:24:05 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.43.230 with SMTP id z6ls3641753igl.25.canary; Wed, 05 Feb 2014 16:24:04 -0800 (PST) X-Received: by 10.50.79.228 with SMTP id m4mr100679igx.9.1391646244350; Wed, 05 Feb 2014 16:24:04 -0800 (PST) In-Reply-To: X-Original-Sender: jesseperla@gmail.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:9135 Archived-At: ------=_Part_7155_10483635.1391646242555 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, we all really appreciate this work. On Wednesday, February 5, 2014 3:48:10 PM UTC-8, =C5=81ukasz Mendakiewicz w= rote: > > 1. *Deal killer* Need Static Row vs. column major support!=20 > =20 > It's there -- *strided_array_view*. We have intentionally kept the=20 > requirements of the provided *stride* lax to accommodate peculiar use=20 > cases such as transposed views (stride is decreasing) or even=20 > "self-aliasing views" (stride =3D 0 in one or more dimensions). > > This of course means that it must be the *strided_array_view* type used= =20 > on interfaces expecting varying ordering. However we believe that it shou= ld=20 > be explicit whether the data can have access pattern that is not "natural= ",=20 > due to all the performance implications. > I recognize that manually specifying the stride might be error-prone,=20 > however I believe that providing wrappers atop constructing such views=20 > would be the responsibility of the specific library furnishing those=20 > column-major containers in the first place, e.g. "strided_array_view= =20 > to_strided_array_view( some_column_major_math_library::matrix& )". > My answer: Ah, I didn't see that. That does it for dynamic orderings like=20 boost::multi_array has. My only problem then is that there is no way to=20 have a static check on the orderings. So it isn't possible to write an=20 adaptor for things that have static storage orderings such as Eigen, ublas,= =20 and most of the others. I also can't tag dispatch to different library=20 functions based on the storage order. =20 > > 2. *Deal killer* operator()(...) support > > Yes, we realized that operator() is the convention, though only as a=20 > workaround because C++ doesn't have multi-argument operator[]. > We have wrestled with whether this is the right time to finally propose= =20 > and add multi-argument operator[] directly, and we will raise this questi= on=20 > in Issaquah. If we had that, that would be clearly the right answer, righ= t? > My answer: For me, the issue is more one of interoperability in making existing code= =20 generic. An enormous amount of software for 2D and 3D containers has been= =20 written with operator() because a multi-argument operator[] didn't exist=20 (see all of the libraries I mentioned and many more). So it makes=20 converting that code to use a generic array_view interface very costly. =20 In the meantime, given we abandon the pre-C++11 intuition, I find using *av= [{3,=20 1, 4}]* much cleaner than *av(3, 1, 4)*. To me, the message operator[]=20 conveys is "accessing data structure (sub-elements)", while operator()=20 should always mean "executing algorithm (calling a function)". It's=20 unfortunate that we ended up with an overloaded meaning of the latter due= =20 to language limitations (cf. C#). Also, it only comes up when you don't=20 already have an *index* object (in which case you'd just write *av[idx]*= and this discussion doesn't matter) but you have integer literals or=20 individual integer variables -- is that really so bad? It seems like the argument is migration from existing code that happens to= =20 use operator() because that's all we had. We understand the need for=20 migration, but if we added operator[,,], then we also want to encourage new= =20 code to be written the right way going forward. Is migrating from=20 operator() syntax really a big deal? If yes, would it be helpful to add a= =20 (redundant) operator() accessor that we immediately also mark=20 [[deprecated]] to discourage use? My answer: In this case, I think it is pretty bad and could hamstring the interface. = =20 I also would prefer a multi-argument [] if building from scratch, but there= =20 is a huge amount of scientific code out there that one would want to make= =20 generic. If it supports operator(), then we can just change our interfaces= =20 to a generic one, and use the implicit concept used throughout array_view.= =20 Adding a redundant operator() seems the easiest solution. A [[deprecated]]= =20 doesn't hurt (as long as you never actually deprecate it). This just=20 doesn't seem like a battle worth fighting over aesthetics to me. > 3. *Would be very nice* reshape() function > > Can you please help me understand what part is missing here with the=20 > functionality of the *array_view* constructor? > You are right, that is enough. =20 > > > 4. *Nice to have sooner rather than later* Fixed size extents > > This is interesting, although as you observed -- it can be separated from= =20 > the "core" proposal into a subsequent one. > I'm also a bit worried with polluting the programming model with the=20 > concept driven mostly by the optimizer rationale. > Having said that -- can you give us some specific motivating examples and= =20 > data? > To me, the biggest motivating examples for this are ensuring adaptability= =20 and ensuring conformance for tensor/matrix operations. *For optimization: *Includes things like SIMD due to fixed extents,=20 managing cache boundaries, etc. that I don't really understand. I also=20 know that this becomes extremely important for geometry. Many libraries=20 have handcrafted optimizations for their algorthms with fixed size=20 matrices/vector (e.g.=20 http://eigen.tuxfamily.org/dox/group__TutorialLinearAlgebra.html shows the= =20 fixed sizes are all over the place). Think through inverting a matrix if= =20 you know it is 2x2 at compiletime and can dispatch to the closed form=20 solution. They will handcraft assembler code to use SSE instructions for= =20 things like inner product if they know it fits in the register. I am=20 always suspicious of premature optimization, but 1) these are the sorts of= =20 optimizations that library vendors (ie. other people) can write with=20 extents known at compiletime, and we can't use them if we don't have the=20 static size information. and (2) with scientific computing small=20 performance changes can have enormous effects in many applciations. *For interoperability:* The ideal here would be that I can take an=20 array_view and create adaptor to eigen/ublas/etc. then use their=20 expression templates for the sematics. But to generate a static eigen=20 vector/matrix, I need to statically query the bounds of the array_view. *For conformance: *Having static sizes can significantly improve=20 correctness in generic code at compiletime. For example, making sure that= =20 an inner product of two 1D slices have the same length at compile time, etc= .. =20 On Tuesday, January 28, 2014 11:45:23 AM UTC-8, Jesse Perla wrote: > I think this is exactly the right approach for the standard. Instead of = a=20 > container, standardize on a view for contiguous or strided memory as a=20 > method for access and interoperability, and then use whatever containers= =20 > you wish in the background. Then adaptors can be written for the various= =20 > scientific and numerical libraries to take one of these objects and conve= rt=20 > into their expression template library. This may have a chance to be a= =20 > standard interoperability format, which is crucially needed for those doi= ng=20 > numerical work. The only way to do it right now is to pass around raw=20 > pointers between disparate libraries with all sorts of manual conversion = in=20 > the middle. > =20 > As use cases for scientific programming, consider the following set of=20 > tests for adaptation: > > 1. Adaptor written which can "convert" this 1D version of boost::ublas= =20 > vector, and 2D of ublas::matrix, COIN-OR dense matrix and vector, Pyth= on=20 > Numpy vector/matrix in C++ libraries, and matlab MEX extension > =20 > 2. Can an efficient adaptor be written for boost numeric_bindings to= =20 > call a variety of libraries (mostly implementations of LAPACK, MUMPS,= =20 > UMFPACK, etc. that are often column-major):=20 > https://svn.boost.org/svn/boost/sandbox/numeric_bindings/boost/numeric= /bindings/.=20 > To see if the correct accessors/types are in array_view, check out th= e=20 > example adaptor implementations in=20 > https://svn.boost.org/svn/boost/sandbox/numeric_bindings/boost/numeric= /bindings/boost/multi_array.hppand=20 > https://svn.boost.org/svn/boost/sandbox/numeric_bindings/boost/numeric= /bindings/eigen/matrix.hpp.=20 > One requirement of this would be that the adaptor class should have n= o=20 > storage of its own. > =20 > =20 > =20 > =20 > From the perspective of scientific computing, the following are some=20 > concerns and additions ordered by necessity: > > - *Deal killer* Need Static row vs. column major support!!!! > - A large number of scientific libraries are written with column=20 > major data. This is especially true when calling high performance= =20 > libraries written in fortran, or interfacing with matlab in MEX. E= VERY=20 > major container used for numerical analysis has this option. > - boost::multi_array allows a runtime specification for the=20 > ordering, but this is overkill. Better is a template parameter whi= ch=20 > determines the ordering for every dimension, and which can be queri= ed by=20 > TMP used in the adaptors. Check out the ordering_type in boost::ub= las,=20 > ColMajor vs. RowMajor in eigen, and the general_storage_order in= =20 > boost::multi_array and seimilar ones in GLAS, MTL, etc. > - If a particular user of the library (e.g. AMP) doesn't want to=20 > work with row-major, then just a static_assert to reject. > - I don't see how this could be added later without breaking a=20 > bunch of generic code. I also can't stress enough how crucial this= is, or=20 > it is pretty much useless for interoperability (and, if you ask me,= doesn't=20 > even belong in a C++ standard as it only creates more implementatio= n noise) > =20 > > - *Deal killer* operator()(...) support > - A good portion of generic code is written with operator(),=20 > especially using 2D specializations. If this doesn't have that as = an=20 > accessing option, then it is too difficult to convert existing code= to be=20 > generic, which will undermine the use of this standard. operator()= code is=20 > much more prevalent here than operator [] > - This should be a variadic accessor for a list of extents, and=20 > doesn't need to have an index_type version. Having a constexpr=20 > specialization would also be nice and allow optimizations, but is n= ot=20 > necessary. > - Examples: ublas, eigen, COIN-OR densematrix, and most others have= =20 > this as their main way to access 1 and 2D matrices. > =20 > > - *Would be very nice* reshape() function > - It would be nice for the user to be able to reshape the array=20 > with the same allocated size. Not resize! An assert could ensure = that the=20 > size remains the same. > - This is very nice for in-place algorithms using huge array's=20 > where the user doesn't want to, or doesn't have the resources to,= =20 > reallocate an entire copy (e.g. transpose) > - It also comes up a lot in numeric analysis with tensor products= =20 > and multivariate regressions. (e.g. using the Kronecker product wi= th vec,=20 > etc.) > =20 > > - *Nice to have sooner rather than later* Fixed size extents > - A fixed_array_view: Pass in a static list of extents as a=20 > variadic template argument. Would not support a reshape() function= as that=20 > would be a different type. Though a conversion function could be w= ritten. > - This enables a huge number of optimizations and compile time=20 > extent checking for errors. Since most of the 1 and 2d array libra= ries=20 > have this, we would be able to pass it around and adapt as required= when=20 > using those algorithms (also SIMD based optimizations) > =20 > > - *Nice to have* RandomAccessContainer and other range-supported=20 > concepts, so that existing STL and future range algorithms could be us= ed=20 > (especially for the 1D version) > =20 > =20 > =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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. ------=_Part_7155_10483635.1391646242555 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, we all really appreciate this work.

On Wedn= esday, February 5, 2014 3:48:10 PM UTC-8, =C5=81ukasz Mendakiewicz wrote:
1. *Deal killer* Need Static Row vs. column major support!
 
It's there -- strided_array_view= . We have intentionally kept the requirements of the provided s= tride lax to accommodate peculiar use cases such as transposed views (s= tride is decreasing) or even "self-aliasing views" (stride =3D 0 in one or = more dimensions).

This of course means that it must be t= he strided_array_view type used on interfaces expecting varying orde= ring. However we believe that it should be explicit whether the data c= an have access pattern that is not "natural", due to all the perf= ormance implications.
I recognize that manually specifying t= he stride might be error-prone, however I believe that providing = wrappers atop constructing such views would be the responsibility of the sp= ecific library furnishing those column-major containers in the first place,= e.g. "strided_array_view<T,2> to_strided_array_view( some_column_maj= or_math_library::matrix<T>& )".

My answer:
Ah, I didn't see that.  That does it for dynamic or= derings like boost::multi_array has.  My only problem then is that the= re is no way to have a static check on the orderings.  So it isn't pos= sible to write an adaptor for things that have static storage orderings suc= h as Eigen, ublas, and most of the others.  I also can't tag dispatch = to different library functions based on the storage order.
 
<= blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord= er-left: 1px #ccc solid;padding-left: 1ex;">

2. *Deal killer* operator()(...) support

Yes, we realized that operator() is the convention, t= hough only as a workaround because C++ doesn't have multi-argument operator= [].
We have wrestl= ed with whether this is the right time to finally propose and add multi-arg= ument operator[] directly, and we will raise this question in Issaquah. If = we had that, that would be clearly the right answer, right?
My answer:
For me, the issue is = more one of interoperability in making existing code generic.  An enor= mous amount of software for 2D and 3D containers has been written with oper= ator() because a multi-argument operator[] didn't exist (see all of the lib= raries I mentioned and many more).  So it makes converting that code t= o use a generic array_view interface very costly.
 
In the meantime, given we abandon the pre-C++11 intuit= ion, I find using av[{3, 1, 4}] much cleaner than av(3, 1, 4= ). To me, the message operator[] conveys is "accessing data structure (= sub-elements)", while operator() should always mean "executing algorithm (c= alling a function)". It's unfortunate that we ended up with an overloaded m= eaning of the latter due to language limitations (cf. C#). Also, = it only comes up when you don't already have an index<N> objec= t (in which case you'd just write av[idx] and this discussion doesn'= t matter) but you have integer literals or individual integer variables -- = is that really so bad?
It seems like the argument is migr= ation from existing code that happens to use operator() because that's all = we had. We understand the need for migration, but if we added operator= [,,], then we also want to encourage new code to be written the right way g= oing forward. Is migrating from operator() syntax really a big deal? If yes= , would it be helpful to add a (redundant) operator() accessor that we imme= diately also mark [[deprecated]] to discourage use?


=
My answer:
In this case, I think it is pretty bad and could hamstri= ng the interface.  I also would prefer a multi-argument [] if building= from=20 scratch, but there is a huge amount of scientific code out there that one w= ould want to make generic.  If it supports=20 operator(), then we can just change our interfaces to a generic one, and use the implicit concept used throughout array_view. Adding a redundant op= erator() seems the easiest solution.  A [[deprecated]] doesn't hurt (a= s long as you never actually deprecate it).  This just doesn't seem li= ke a battle worth fighting over aesthetics to me.


3. *Would be very nice* reshape() function

Can you please he= lp me understand what part is missing here with the functionality of the&nb= sp;array_view constructor?
You are righ= t, that is enough.
 


4. *Nice to have sooner rather than later* Fixed size extents

This is interesting, although as you observed -- it can be separated from= the "core" proposal into a subsequent one.
I'm also a bit worrie= d with polluting the programming model with the concept driven mostly by th= e optimizer rationale.
Having said that -- can you give us some s= pecific motivating examples and data?

To me, the biggest motivating examples for this are ensuring adapta= bility and ensuring conformance for tensor/matrix operations.

For= optimization: Includes things like SIMD due to fixed extents, managing= cache boundaries, etc. that I don't really understand.  I also know t= hat this becomes extremely important for geometry.  Many libraries hav= e handcrafted optimizations for their algorthms with fixed size matrices/ve= ctor (e.g. http://eigen.tuxfamily.org/dox/group__TutorialLinearAlgebra.html= shows the fixed sizes are all over the place).  Think through inverti= ng a matrix  if you know it is 2x2 at compiletime and can dispatch to = the closed form solution.  They will handcraft assembler code to use S= SE instructions for things like inner product if they know it fits in the r= egister.  I am always suspicious of premature optimization, but 1) the= se are the sorts of optimizations that library vendors (ie. other people) c= an write with extents known at compiletime, and we can't use them if we don= 't have the static size information. and (2) with scientific computing smal= l performance changes can have enormous effects in many applciations.
For interoperability: The ideal here would be that I can take an array= _view and create adaptor to eigen/ublas/etc.  then use their expressio= n templates for the sematics.  But to generate a static eigen vector/m= atrix, I need to statically query the bounds of the array_view.
For c= onformance: Having static sizes can significantly improve correctness i= n generic code at compiletime.  For example, making sure that an inner= product of two 1D slices have the same length at compile time, etc.


 
On Tuesday, January 2= 8, 2014 11:45:23 AM UTC-8, Jesse Perla wrote:
=
I think this is exactly the right approach for the st= andard.  Instead of a container, standardize on a view for contiguous = or strided memory as a method for access and interoperability, and then use= whatever containers you wish in the background.  Then adaptors can be= written for the various scientific and numerical libraries to take one of = these objects and convert into their expression template library.  Thi= s may have a chance to be a standard interoperability format, which is cruc= ially needed for those doing numerical work.  The only way to do it ri= ght now is to pass around raw pointers between disparate libraries with all= sorts of manual conversion in the middle.
 
As use cases for scientific programming, consider the following set o= f tests for adaptation:
  1. Adaptor written which can "conver= t" this 1D version of boost::ublas vector, and 2D of ublas::matrix, COIN-OR= dense matrix and vector, Python Numpy vector/matrix in C++ libraries, and = matlab MEX extension
     
  2. Can an efficient adaptor be w= ritten for boost numeric_bindings to call a variety of libraries (mostly im= plementations of LAPACK, MUMPS, UMFPACK, etc. that are often column-major):= https://= svn.boost.org/svn/boost/sandbox/numeric_bindings/boost/numeric/bindings/.  To see if the correct accessors/types are in array_= view, check out the example adaptor implementations in https://svn.boost.org/svn/boost/sa= ndbox/numeric_bindings/boost/numeric/bindings/boost/multi_array.h= pp and https://svn.boost.org/= svn/boost/sandbox/numeric_bindings/boost/numeric/bindings/ei= gen/matrix.hpp.  One requirement of this would be that the adaptor= class should have no storage of its own.
     
<= div>
 
 
From the perspe= ctive of scientific computing, the following are some concerns and addition= s ordered by necessity:
  • *Deal killer* Need Static row vs.= column major support!!!!
    • A large number of scientific librarie= s are written with column major data.  This is especially true when ca= lling high performance libraries written in fortran, or interfacing with ma= tlab in MEX.  EVERY major container used for numerical analysis has th= is option.
    • boost::multi_array allows a runtime specification for th= e ordering, but this is overkill.  Better is a template parameter whic= h determines the ordering for every dimension, and which can be queried by = TMP used in the adaptors.  Check out the ordering_type in boost::ublas= ,  ColMajor vs. RowMajor in eigen, and the general_storage_order in bo= ost::multi_array and seimilar ones in GLAS, MTL, etc.
    • If a particul= ar user of the library (e.g. AMP) doesn't want to work with row-major, then= just a static_assert to reject.
    • I don't see how this could be adde= d later without breaking a bunch of generic code.  I also can't stress= enough how crucial this is, or it is pretty much useless for interoperabil= ity (and, if you ask me, doesn't even belong in a C++ standard as it only c= reates more implementation noise)
  • *Deal ki= ller* operator()(...) support
    • A good portion of generic code is= written with operator(), especially using 2D specializations.  If thi= s doesn't have that as an accessing option, then it is too difficult to con= vert existing code to be generic, which will undermine the use of this stan= dard.  operator() code is much more prevalent here than operator []
    • This should be a variadic accessor for a list of extents, and doesn't= need to have an index_type version.  Having a constexpr specializatio= n would also be nice and allow optimizations, but is not necessary.
      • Examples: ublas, eigen, COIN-OR densematrix, and most others have this as = their main way to access 1 and 2D matrices.
    *Would be very nice* reshape() function
    • It would be nice for = the user to be able to reshape the array with the same allocated size. &nbs= p;Not resize!  An assert could ensure that the size remains the same.<= /li>
    • This is very nice for in-place algorithms using huge array's where = the user doesn't want to, or doesn't have the resources to, reallocate an e= ntire copy (e.g. transpose)
    • It also comes up a lot in numeric analy= sis with tensor products and multivariate regressions.  (e.g. using th= e Kronecker product with vec, etc.)
  • *Nice = to have sooner rather than later* Fixed size extents
    • A fixed_ar= ray_view: Pass in a static list of extents as a variadic template argument.=  Would not support a reshape() function as that would be a different = type.  Though a conversion function could be written.
    • This ena= bles a huge number of optimizations and compile time extent checking for er= rors.  Since most of the 1 and 2d array libraries have this, we would = be able to pass it around and adapt as required when using those algorithms= (also SIMD based optimizations)
  • *Nice to = have* RandomAccessContainer and other range-supported concepts, so that exi= sting STL and future range algorithms could be used (especially for the 1D = version)
     
 
=

--
 
---
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-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/<= /a>.
------=_Part_7155_10483635.1391646242555-- .