------=_Part_3585_23543222.1390938323546
Content-Type: text/plain; charset=UTF-8

I think this is exactly the right approach for the standard.  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.  This may have a chance to be a
standard interoperability format, which is crucially needed for those doing
numerical work.  The only way to do it right 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 of
tests for adaptation:

   1. Adaptor written which can "convert" 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 written for boost numeric_bindings to
   call a variety of libraries (mostly implementations 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/sandbox/numeric_bindings/boost/numeric/bindings/boost/multi_array.hpp
   and
   https://svn.boost.org/svn/boost/sandbox/numeric_bindings/boost/numeric/bindings/eigen/matrix.hpp.
    One requirement of this would be that the adaptor class should have no
   storage of its own.



From the perspective of scientific computing, the following are some
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
      major data.  This is especially true when calling high performance
      libraries written in fortran, or interfacing with matlab in MEX.  EVERY
      major container used for numerical analysis has this option.
      - boost::multi_array allows a runtime specification for the ordering,
      but this is overkill.  Better is a template parameter which 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 boost::multi_array and
      seimilar ones in GLAS, MTL, etc.
      - If a particular 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 added 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 interoperability (and, if you ask me, doesn't even
      belong in a C++ standard as it only creates more implementation noise)


   - *Deal killer* operator()(...) support
      - A good portion of generic code is written with operator(),
      especially using 2D specializations.  If this doesn't have that as an
      accessing option, then it is too difficult to convert existing code to be
      generic, which will undermine the use of this standard.  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
      specialization 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.  Not resize!  An assert could ensure that the size
      remains the same.
      - 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
      entire copy (e.g. transpose)
      - It also comes up a lot in numeric analysis with tensor products and
      multivariate regressions.  (e.g. using the Kronecker product with vec, etc.)


   - *Nice to have sooner rather than later* Fixed size extents
      - A fixed_array_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 enables a huge number of optimizations and compile time extent
      checking for errors.  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 existing 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 "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_3585_23543222.1390938323546
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I think this is exactly the right approach for the st=
andard. &nbsp;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. &nbsp;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. &nbsp;Thi=
s may have a chance to be a standard interoperability format, which is cruc=
ially needed for those doing numerical work. &nbsp;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.</div><div><br></div><div>As use =
cases for scientific programming, consider the following set of tests for a=
daptation:</div><div><ol><li>Adaptor written which can "convert" this 1D ve=
rsion 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 ex=
tension<br></li><li>Can an efficient adaptor be written for boost numeric_b=
indings to call a variety of libraries (mostly implementations of LAPACK, M=
UMPS, UMFPACK, etc. that are often column-major): https://svn.boost.org/svn=
/boost/sandbox/numeric_bindings/boost/numeric/bindings/. &nbsp;To see if th=
e correct accessors/types are in array_view, check out the example adaptor =
implementations in https://svn.boost.org/svn/boost/sandbox/numeric_bindings=
/boost/numeric/bindings/boost/multi_array.hpp and https://svn.boost.org/svn=
/boost/sandbox/numeric_bindings/boost/numeric/bindings/eigen/matrix.hpp. &n=
bsp;One requirement of this would be that the adaptor class should have no =
storage of its own.<br></li></ol></div><div><br></div><div><br></div><div>F=
rom the perspective of scientific computing, the following are some concern=
s and additions ordered by necessity:</div><div><ul><li>*Deal killer* Need =
Static row vs. column major support!!!!</li><ul><li>A large number of scien=
tific libraries are written with column major data. &nbsp;This is especiall=
y true when calling high performance libraries written in fortran, or inter=
facing with matlab in MEX. &nbsp;EVERY major container used for numerical a=
nalysis has this option.</li><li>boost::multi_array allows a runtime specif=
ication for the ordering, but this is overkill. &nbsp;Better is a template =
parameter which determines the ordering for every dimension, and which can =
be queried by TMP used in the adaptors. &nbsp;Check out the ordering_type i=
n boost::ublas, &nbsp;ColMajor vs. RowMajor in eigen, and the general_stora=
ge_order in boost::multi_array and seimilar ones in GLAS, MTL, etc.</li><li=
>If a particular user of the library (e.g. AMP) doesn't want to work with r=
ow-major, then just a static_assert to reject.</li><li>I don't see how this=
 could be added later without breaking a bunch of generic code. &nbsp;I als=
o can't stress enough how crucial this is, or it is pretty much useless for=
 interoperability (and, if you ask me, doesn't even belong in a C++ standar=
d as it only creates more implementation noise)</li></ul></ul></div><div><u=
l><li>*Deal killer* operator()(...) support</li><ul><li>A good portion of g=
eneric code is written with operator(), especially using 2D specializations=
.. &nbsp;If this doesn't have that as an accessing option, then it is too di=
fficult to convert existing code to be generic, which will undermine the us=
e of this standard. &nbsp;operator() code is much more prevalent here than =
operator []</li><li>This should be a variadic accessor for a list of extent=
s, and doesn't need to have an index_type version. &nbsp;Having a constexpr=
 specialization would also be nice and allow optimizations, but is not nece=
ssary.</li><li>Examples: ublas, eigen, COIN-OR densematrix, and most others=
 have this as their main way to access 1 and 2D matrices.</li></ul></ul></d=
iv><div><ul><li>*Would be very nice* reshape() function</li><ul><li>It woul=
d be nice for the user to be able to reshape the array with the same alloca=
ted size. &nbsp;Not resize! &nbsp;An assert could ensure that the size rema=
ins the same.</li><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, r=
eallocate an entire copy (e.g. transpose)</li><li>It also comes up a lot in=
 numeric analysis with tensor products and multivariate regressions. &nbsp;=
(e.g. using the Kronecker product with vec, etc.)</li></ul></ul></div><div>=
<ul><li>*Nice to have sooner rather than later* Fixed size extents</li><ul>=
<li>A fixed_array_view: Pass in a static list of extents as a variadic temp=
late argument. &nbsp;Would not support a reshape() function as that would b=
e a different type. &nbsp;Though a conversion function could be written.</l=
i><li>This enables a huge number of optimizations and compile time extent c=
hecking for errors. &nbsp;Since most of the 1 and 2d array libraries have t=
his, we would be able to pass it around and adapt as required when using th=
ose algorithms (also SIMD based optimizations)</li></ul></ul></div><div><ul=
><li>*Nice to have* RandomAccessContainer and other range-supported concept=
s, so that existing STL and future range algorithms could be used (especial=
ly for the 1D version)<br></li></ul></div><div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3585_23543222.1390938323546--

.