------=_Part_3720_15577204.1391402363360
Content-Type: text/plain; charset=UTF-8

Why not complement this with an improved array<T, int...> that can be used
to generate a n-dimensional array, and fall backs to the current array<T,
int> when one size is given. A specialized array<T> could be defined also,
which provides runtime bounds using a similar int... constructor. The
drawback is that now not even the rank is defined at compile time
(array_view<T, int rank> vs array<T, int size>). So a new name is required,
I guess. Maybe valarray can be generalized to n dimensions: valarray<T, int
rank = 1>.

Or would this break code like this:

template<typename T> my_func(valarray<T>& arr);   // does the default
template parameter kick in here or not?



Den tisdagen den 28:e januari 2014 kl. 20:45:23 UTC+1 skrev Jesse Perla:
>
> 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.hppand
>    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_3720_15577204.1391402363360
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Why not complement this with an improved array&lt;T, int..=
..&gt; that can be used to generate a n-dimensional array, and fall backs to=
 the current array&lt;T, int&gt; when one size is given. A specialized arra=
y&lt;T&gt; could be defined also, which provides runtime bounds using a sim=
ilar int... constructor. The drawback is that now not even the rank is defi=
ned at compile time (array_view&lt;T, int rank&gt; vs array&lt;T, int size&=
gt;). So a new name is required, I guess. Maybe valarray can be generalized=
 to n dimensions: valarray&lt;T, int rank =3D 1&gt;.<div><br></div><div>Or =
would this break code like this:</div><div><br></div><div>template&lt;typen=
ame T&gt; my_func(valarray&lt;T&gt;&amp; arr); &nbsp; // does the default t=
emplate parameter kick in here or not?<br><div><br></div><div><br><br>Den t=
isdagen den 28:e januari 2014 kl. 20:45:23 UTC+1 skrev Jesse Perla:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>I think this is =
exactly the right approach for the standard. &nbsp;Instead of a container, =
standardize on a view for contiguous or strided memory as a method for acce=
ss and interoperability, and then use whatever containers you wish in the b=
ackground. &nbsp;Then adaptors can be written for the various scientific an=
d numerical libraries to take one of these objects and convert into their e=
xpression template library. &nbsp;This may have a chance to be a standard i=
nteroperability format, which is crucially needed for those doing numerical=
 work. &nbsp;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 mid=
dle.</div><div><br></div><div>As use cases for scientific programming, cons=
ider the following set of tests for adaptation:</div><div><ol><li>Adaptor w=
ritten which can "convert" this 1D version of boost::ublas vector, and 2D o=
f ublas::matrix, COIN-OR dense matrix and vector, Python Numpy vector/matri=
x in C++ libraries, and matlab MEX extension<br></li><li>Can an efficient a=
daptor be written for boost numeric_bindings to call a variety of libraries=
 (mostly implementations of LAPACK, MUMPS, UMFPACK, etc. that are often col=
umn-major): <a href=3D"https://svn.boost.org/svn/boost/sandbox/numeric_bind=
ings/boost/numeric/bindings/" target=3D"_blank" onmousedown=3D"this.href=3D=
'https://www.google.com/url?q\75https%3A%2F%2Fsvn.boost.org%2Fsvn%2Fboost%2=
Fsandbox%2Fnumeric_bindings%2Fboost%2Fnumeric%2Fbindings%2F\46sa\75D\46sntz=
\0751\46usg\75AFQjCNFhNKBTnvDMHUmGVfcgXpWX0J7Mnw';return true;" onclick=3D"=
this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fsvn.boost.org%2Fs=
vn%2Fboost%2Fsandbox%2Fnumeric_bindings%2Fboost%2Fnumeric%2Fbindings%2F\46s=
a\75D\46sntz\0751\46usg\75AFQjCNFhNKBTnvDMHUmGVfcgXpWX0J7Mnw';return true;"=
>https://svn.boost.org/svn/<wbr>boost/sandbox/numeric_<wbr>bindings/boost/n=
umeric/<wbr>bindings/</a>. &nbsp;To see if the correct accessors/types are =
in array_view, check out the example adaptor implementations in <a href=3D"=
https://svn.boost.org/svn/boost/sandbox/numeric_bindings/boost/numeric/bind=
ings/boost/multi_array.hpp" target=3D"_blank" onmousedown=3D"this.href=3D'h=
ttps://www.google.com/url?q\75https%3A%2F%2Fsvn.boost.org%2Fsvn%2Fboost%2Fs=
andbox%2Fnumeric_bindings%2Fboost%2Fnumeric%2Fbindings%2Fboost%2Fmulti_arra=
y.hpp\46sa\75D\46sntz\0751\46usg\75AFQjCNGQAR7YmaGZC7_Mvi8rVXkNhKYt4w';retu=
rn true;" onclick=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2=
F%2Fsvn.boost.org%2Fsvn%2Fboost%2Fsandbox%2Fnumeric_bindings%2Fboost%2Fnume=
ric%2Fbindings%2Fboost%2Fmulti_array.hpp\46sa\75D\46sntz\0751\46usg\75AFQjC=
NGQAR7YmaGZC7_Mvi8rVXkNhKYt4w';return true;">https://svn.boost.org/svn/<wbr=
>boost/sandbox/numeric_<wbr>bindings/boost/numeric/<wbr>bindings/boost/mult=
i_array.hpp</a> and <a href=3D"https://svn.boost.org/svn/boost/sandbox/nume=
ric_bindings/boost/numeric/bindings/eigen/matrix.hpp" target=3D"_blank" onm=
ousedown=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fsvn.b=
oost.org%2Fsvn%2Fboost%2Fsandbox%2Fnumeric_bindings%2Fboost%2Fnumeric%2Fbin=
dings%2Feigen%2Fmatrix.hpp\46sa\75D\46sntz\0751\46usg\75AFQjCNGDoUYcES8xClz=
ou_kVsLYwCFvzsA';return true;" onclick=3D"this.href=3D'https://www.google.c=
om/url?q\75https%3A%2F%2Fsvn.boost.org%2Fsvn%2Fboost%2Fsandbox%2Fnumeric_bi=
ndings%2Fboost%2Fnumeric%2Fbindings%2Feigen%2Fmatrix.hpp\46sa\75D\46sntz\07=
51\46usg\75AFQjCNGDoUYcES8xClzou_kVsLYwCFvzsA';return true;">https://svn.bo=
ost.org/svn/<wbr>boost/sandbox/numeric_<wbr>bindings/boost/numeric/<wbr>bin=
dings/eigen/matrix.hpp</a>. &nbsp;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>From the perspective of scientific computing, =
the following are some concerns and additions ordered by necessity:</div><d=
iv><ul><li>*Deal killer* Need Static row vs. column major support!!!!</li><=
ul><li>A large number of scientific libraries are written with column major=
 data. &nbsp;This is especially true when calling high performance librarie=
s written in fortran, or interfacing with matlab in MEX. &nbsp;EVERY major =
container used for numerical analysis has this option.</li><li>boost::multi=
_array allows a runtime specification for the ordering, but this is overkil=
l. &nbsp;Better is a template parameter which determines the ordering for e=
very dimension, and which can be queried by TMP used in the adaptors. &nbsp=
;Check out the ordering_type in boost::ublas, &nbsp;ColMajor vs. RowMajor i=
n eigen, and the general_storage_order in boost::multi_array and seimilar o=
nes in GLAS, MTL, etc.</li><li>If a particular user of the library (e.g. AM=
P) doesn't want to work with row-major, then just a static_assert to reject=
..</li><li>I don't see how this could be added later without breaking a bunc=
h of generic code. &nbsp;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 nois=
e)</li></ul></ul></div><div><ul><li>*Deal killer* operator()(...) support</=
li><ul><li>A good portion of generic code is written with operator(), espec=
ially using 2D specializations. &nbsp;If this doesn't have that as an acces=
sing option, then it is too difficult to convert existing code to be generi=
c, which will undermine the use 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 extents, and doesn't need to have an index_type ver=
sion. &nbsp;Having a constexpr specialization would also be nice and allow =
optimizations, but is not necessary.</li><li>Examples: ublas, eigen, COIN-O=
R densematrix, and most others have this as their main way to access 1 and =
2D matrices.</li></ul></ul></div><div><ul><li>*Would be very nice* reshape(=
) function</li><ul><li>It would be nice for the user to be able to reshape =
the array with the same allocated size. &nbsp;Not resize! &nbsp;An assert c=
ould ensure that the size remains the same.</li><li>This is very nice for i=
n-place algorithms using huge array's where the user doesn't want to, or do=
esn't have the resources to, reallocate an entire copy (e.g. transpose)</li=
><li>It also comes up a lot in numeric analysis with tensor products and mu=
ltivariate regressions. &nbsp;(e.g. using the Kronecker product with vec, e=
tc.)</li></ul></ul></div><div><ul><li>*Nice to have sooner rather than late=
r* Fixed size extents</li><ul><li>A fixed_array_view: Pass in a static list=
 of extents as a variadic template argument. &nbsp;Would not support a resh=
ape() function as that would be a different type. &nbsp;Though a conversion=
 function could be written.</li><li>This enables a huge number of optimizat=
ions and compile time extent checking for errors. &nbsp;Since most of the 1=
 and 2d array libraries have this, we would be able to pass it around and a=
dapt as required when using those algorithms (also SIMD based optimizations=
)</li></ul></ul></div><div><ul><li>*Nice to have* RandomAccessContainer and=
 other range-supported concepts, so that existing STL and future range algo=
rithms could be used (especially for the 1D version)<br></li></ul></div><di=
v><br></div></div></blockquote></div></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_3720_15577204.1391402363360--

.

------=_Part_2001_9342179.1391457497914
Content-Type: text/plain; charset=UTF-8


On Sunday, February 2, 2014 8:39:23 PM UTC-8, Bengt Gustafsson wrote:
>
> Why not complement this with an improved array<T, int...> that can be used
> to generate a n-dimensional array, and fall backs to the current array<T,
> int> when one size is given. A specialized array<T> could be defined also,
> which provides runtime bounds using a similar int... constructor. The
> drawback is that now not even the rank is defined at compile time
> (array_view<T, int rank> vs array<T, int size>). So a new name is required,
> I guess. Maybe valarray can be generalized to n dimensions: valarray<T, int
> rank = 1>.
>
>>
>> My only issue is that the most important thing scientific computing needs
is an inter-operable and adaptable view rather than yet another container -
and hence a fixed extent array_view seems more important than the
container.  I would just hate for adding features to slow down something so
important for interoperability.

That said, it certainly couldn't hurt (conditional on it being  array<T,
int..., StorageType = row_major>, and allowing operator() support, of
course, as discussed above ).  I think it is important to separate the
fixed size array from the dynamically allocated valarray and vector and
maintain naming consistency.  If the interfaces can't be adjusted, perhaps
multi_array, multi_valarray, and multi_vector are good enough, but I don't
have strong opinions.

On that note for naming consistency: what would the inevitable fixed extent
version of array_view would be called for constency with containers?  if
arrays have fixed exents in the std, then why would the array_view have
dynamic constraints, and what would the fixed extent version of the
array_view be called?  I realize that the boost multi_array is for dynamic
extents, but that predates some of the other naming.


--

---
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_2001_9342179.1391457497914
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Sunday, February 2, 2014 8:39:23 PM UTC-8, Bengt Gu=
stafsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">Why not complement this with an improved array&lt;T, int...&gt; that can =
be used to generate a n-dimensional array, and fall backs to the current ar=
ray&lt;T, int&gt; when one size is given. A specialized array&lt;T&gt; coul=
d be defined also, which provides runtime bounds using a similar int... con=
structor. The drawback is that now not even the rank is defined at compile =
time (array_view&lt;T, int rank&gt; vs array&lt;T, int size&gt;). So a new =
name is required, I guess. Maybe valarray can be generalized to n dimension=
s: valarray&lt;T, int rank =3D 1&gt;.<div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><br></div></blockquote></div></div></blockquote><di=
v><div>My only issue is that the most important thing scientific computing =
needs is an inter-operable and adaptable view rather than yet another conta=
iner - and hence a fixed extent array_view seems more important than the co=
ntainer. &nbsp;I would just hate for adding features to slow down something=
 so important for interoperability.</div></div><div><br></div><div>That sai=
d, it certainly couldn't hurt (conditional on it being&nbsp;&nbsp;array&lt;=
T, int..., StorageType =3D row_major&gt;, and allowing operator() support, =
of course, as discussed above ). &nbsp;I think it is important to separate =
the fixed size array from the dynamically allocated valarray and vector and=
 maintain naming consistency. &nbsp;If the interfaces can't be adjusted, pe=
rhaps multi_array, multi_valarray, and multi_vector are good enough, but I =
don't have strong opinions.</div><div><br></div><div>On that note for namin=
g consistency: what would the inevitable fixed extent version of array_view=
 would be called for constency with containers? &nbsp;if arrays have fixed =
exents in the std, then why would the array_view have dynamic constraints, =
and what would the fixed extent version of the array_view be called? &nbsp;=
I realize that the boost multi_array is for dynamic extents, but that preda=
tes some of the other naming.</div><div><br></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_2001_9342179.1391457497914--

.

------=_Part_4729_28513374.1391480028305
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I totally agree that array_view is more important, but I think there should=
=20
be at least one container in std for which array_view is an appropriate=20
slice. This to avoid that future numerics libraries continue designing=20
their own matrix types forever.

I also thought about the compile time constant array_view requirement. This=
=20
is rather complex as we want to support slicing of n-dimensional arrays. I=
=20
mean: There are so many combinations of fixed and variable. Consider for=20
instance the totally feasible case of a 3x3 subarray of any larger matrix.=
=20
Here both sizes are fixed, but we need in addition store a pointer to the=
=20
corner of the actual data and a line stride. Now add higher ranks,=20
transposition (reordering of dimensions in the general case), mirroring and=
=20
sparse strides "every other data" and it really blows up in your face.=20
Strangely enough the complexity exists only when defining the slice, not=20
when using it. Then it is only a matter of multiplying each index by its=20
own precalculated coefficient and then add the start pointer. idx iteration=
=20
should also be quite simple.

I guess there should be libraries that have done this. I remember one=20
called MTL, but that was super complex to use. We still need simple cases=
=20
to be simple. Some kind of template parameter composition system is what=20
springs to mind, but I don't know how it should look like or how to=20
implement...

Something like:

array_slice<3, transpose<1,2>, mirror<0>, size<0, 3>>    // 3d slice with y=
=20
and z exchanged, x mirrored and a fixed size of 3 in x.

it might work using variadic templates but the implementation won't be=20
pretty. Constructor signatures must be adapted to what is fixed and will be=
=20
really hard to remember. std namespace will be bloated.

Better:

array_view<3>::transpose<1, 2>::mirror<0>::size<0, 3>

Beware all those 'typename's I didn't write here. Kind of destroys it!

Den m=C3=A5ndagen den 3:e februari 2014 kl. 20:58:17 UTC+1 skrev Jesse Perl=
a:
>
>
> On Sunday, February 2, 2014 8:39:23 PM UTC-8, Bengt Gustafsson wrote:
>>
>> Why not complement this with an improved array<T, int...> that can be=20
>> used to generate a n-dimensional array, and fall backs to the current=20
>> array<T, int> when one size is given. A specialized array<T> could be=20
>> defined also, which provides runtime bounds using a similar int...=20
>> constructor. The drawback is that now not even the rank is defined at=20
>> compile time (array_view<T, int rank> vs array<T, int size>). So a new n=
ame=20
>> is required, I guess. Maybe valarray can be generalized to n dimensions:=
=20
>> valarray<T, int rank =3D 1>.
>>
>>>
>>> My only issue is that the most important thing scientific computing=20
> needs is an inter-operable and adaptable view rather than yet another=20
> container - and hence a fixed extent array_view seems more important than=
=20
> the container.  I would just hate for adding features to slow down=20
> something so important for interoperability.
>
> That said, it certainly couldn't hurt (conditional on it being  array<T,=
=20
> int..., StorageType =3D row_major>, and allowing operator() support, of=
=20
> course, as discussed above ).  I think it is important to separate the=20
> fixed size array from the dynamically allocated valarray and vector and=
=20
> maintain naming consistency.  If the interfaces can't be adjusted, perhap=
s=20
> multi_array, multi_valarray, and multi_vector are good enough, but I don'=
t=20
> have strong opinions.
>
> On that note for naming consistency: what would the inevitable fixed=20
> extent version of array_view would be called for constency with container=
s?=20
>  if arrays have fixed exents in the std, then why would the array_view ha=
ve=20
> dynamic constraints, and what would the fixed extent version of the=20
> array_view be called?  I realize that the boost multi_array is for dynami=
c=20
> extents, but that predates some of the other naming.
>
>
>

--=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_4729_28513374.1391480028305
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I totally agree that array_view is more important, but I t=
hink there should be at least one container in std for which array_view is =
an appropriate slice. This to avoid that future numerics libraries continue=
 designing their own matrix types forever.<div><br></div><div>I also though=
t about the compile time constant array_view requirement. This is rather co=
mplex as we want to support slicing of n-dimensional arrays. I mean: There =
are so many combinations of fixed and variable. Consider for instance the t=
otally feasible case of a 3x3 subarray of any larger matrix. Here both size=
s are fixed, but we need in addition store a pointer to the corner of the a=
ctual data and a line stride. Now add higher ranks, transposition (reorderi=
ng of dimensions in the general case), mirroring and sparse strides "every =
other data" and it really blows up in your face. Strangely enough the compl=
exity exists only when defining the slice, not when using it. Then it is on=
ly a matter of multiplying each index by its own precalculated coefficient =
and then add the start pointer. idx iteration should also be quite simple.<=
/div><div><br></div><div>I guess there should be libraries that have done t=
his. I remember one called MTL, but that was super complex to use. We still=
 need simple cases to be simple. Some kind of template parameter compositio=
n system is what springs to mind, but I don't know how it should look like =
or how to implement...</div><div><br></div><div>Something like:</div><div><=
br></div><div>array_slice&lt;3, transpose&lt;1,2&gt;, mirror&lt;0&gt;, size=
&lt;0, 3&gt;&gt; &nbsp; &nbsp;// 3d slice with y and z exchanged, x mirrore=
d and a fixed size of 3 in x.</div><div><br></div><div>it might work using =
variadic templates but the implementation won't be pretty. Constructor sign=
atures must be adapted to what is fixed and will be really hard to remember=
.. std namespace will be bloated.</div><div><br></div><div>Better:</div><div=
><br></div><div>array_view&lt;3&gt;::transpose&lt;1, 2&gt;::mirror&lt;0&gt;=
::size&lt;0, 3&gt;</div><div><br></div><div><span style=3D"font-size: 13px;=
">Beware all those 'typename's I didn't write here. Kind of destroys it!</s=
pan><br></div><div><br>Den m=C3=A5ndagen den 3:e februari 2014 kl. 20:58:17=
 UTC+1 skrev Jesse Perla:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><br>On Sunday, February 2, 2014 8:39:23 PM UTC-8, Bengt Gustafs=
son wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Why not =
complement this with an improved array&lt;T, int...&gt; that can be used to=
 generate a n-dimensional array, and fall backs to the current array&lt;T, =
int&gt; when one size is given. A specialized array&lt;T&gt; could be defin=
ed also, which provides runtime bounds using a similar int... constructor. =
The drawback is that now not even the rank is defined at compile time (arra=
y_view&lt;T, int rank&gt; vs array&lt;T, int size&gt;). So a new name is re=
quired, I guess. Maybe valarray can be generalized to n dimensions: valarra=
y&lt;T, int rank =3D 1&gt;.<div><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><br></div></blockquote></div></div></blockquote><div><div>My =
only issue is that the most important thing scientific computing needs is a=
n inter-operable and adaptable view rather than yet another container - and=
 hence a fixed extent array_view seems more important than the container. &=
nbsp;I would just hate for adding features to slow down something so import=
ant for interoperability.</div></div><div><br></div><div>That said, it cert=
ainly couldn't hurt (conditional on it being&nbsp;&nbsp;array&lt;T, int...,=
 StorageType =3D row_major&gt;, and allowing operator() support, of course,=
 as discussed above ). &nbsp;I think it is important to separate the fixed =
size array from the dynamically allocated valarray and vector and maintain =
naming consistency. &nbsp;If the interfaces can't be adjusted, perhaps mult=
i_array, multi_valarray, and multi_vector are good enough, but I don't have=
 strong opinions.</div><div><br></div><div>On that note for naming consiste=
ncy: what would the inevitable fixed extent version of array_view would be =
called for constency with containers? &nbsp;if arrays have fixed exents in =
the std, then why would the array_view have dynamic constraints, and what w=
ould the fixed extent version of the array_view be called? &nbsp;I realize =
that the boost multi_array is for dynamic extents, but that predates some o=
f the other naming.</div><div><br></div><div><br></div></div></blockquote><=
/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_4729_28513374.1391480028305--

.

------=_Part_1285_14829586.1391486109124
Content-Type: text/plain; charset=UTF-8


On Monday, February 3, 2014 6:13:48 PM UTC-8, Bengt Gustafsson wrote:
>
> I totally agree that array_view is more important, but I think there
> should be at least one container in std for which array_view is an
> appropriate slice. This to avoid that future numerics libraries continue
> designing their own matrix types forever.
>

Based on my frustrating years of trying to patch together libraries, I fear
that due to the complexity and idiosyncratic preferences for expression
template libraries for linear algebra and tensor semantics, it will
continue.  That said, you are right that with a basic container some of
these other libraries could have adaptors to use them as the internal
storage.


> I also thought about the compile time constant array_view requirement.
> This is rather complex as we want to support slicing of n-dimensional
> arrays. I mean: There are so many combinations of fixed and variable.
> Consider for instance the totally feasible case of a 3x3 subarray of any
> larger matrix. Here both sizes
>
are fixed, but we need in addition store a pointer to the corner of the
> actual data and a line stride. Now add higher ranks, transposition
> (reordering of dimensions in the general case), mirroring and sparse
> strides "every other data" and it really blows up in your face. Strangely
> enough the complexity exists only when defining the slice, not when using
> it. Then it is only a matter of multiplying each index by its own
> precalculated coefficient and then add the start pointer. idx iteration
> should also be quite simple.
>

I think that you were thinking a lot more functionality than I had in my
mind.  But you are probably right, and it does need the strides.  I have
always thought that boost::multi_array and blitz overdid it:
(http://www.boost.org/doc/libs/1_55_0b1/libs/multi_array/doc/user.html#sec_views
  and http://blitz.sourceforge.net/resources/blitz-0.9.pdf)

Assuming that things are kept to the 1st order features (i.e. slices on one
dimension, contiguous subarrays, no transpose or mirror for now, etc.), it
seems like the only dynamic memory necessary would be the pointer, and then
static data as the list of extents and the list of strides.  You are right
that constexpr math for the indexing can't work otherwise.

--

---
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_1285_14829586.1391486109124
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Monday, February 3, 2014 6:13:48 PM UTC-8, Bengt Gu=
stafsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">I totally agree that array_view is more important, but I think there shou=
ld be at least one container in std for which array_view is an appropriate =
slice. This to avoid that future numerics libraries continue designing thei=
r own matrix types forever.</div></blockquote><div><br></div><div>Based on =
my frustrating years of trying to patch together libraries, I fear that due=
 to the complexity and idiosyncratic preferences for expression template li=
braries for linear algebra and tensor semantics, it will continue. &nbsp;Th=
at said, you are right that with a basic container some of these other libr=
aries could have adaptors to use them as the internal storage.</div><div>&n=
bsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v>I also thought about the compile time constant array_view requirement. Th=
is is rather complex as we want to support slicing of n-dimensional arrays.=
 I mean: There are so many combinations of fixed and variable. Consider for=
 instance the totally feasible case of a 3x3 subarray of any larger matrix.=
 Here both sizes</div></div></blockquote><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><div>are fixed, but we need in addition store a=
 pointer to the corner of the actual data and a line stride. Now add higher=
 ranks, transposition (reordering of dimensions in the general case), mirro=
ring and sparse strides "every other data" and it really blows up in your f=
ace. Strangely enough the complexity exists only when defining the slice, n=
ot when using it. Then it is only a matter of multiplying each index by its=
 own precalculated coefficient and then add the start pointer. idx iteratio=
n should also be quite simple.</div></div></blockquote><div>&nbsp;</div><di=
v>I think that you were thinking a lot more functionality than I had in my =
mind. &nbsp;But you are probably right, and it does need the strides. &nbsp=
;I have always thought that boost::multi_array and blitz overdid it: (http:=
//www.boost.org/doc/libs/1_55_0b1/libs/multi_array/doc/user.html#sec_views =
&nbsp; and&nbsp;http://blitz.sourceforge.net/resources/blitz-0.9.pdf)</div>=
<div><br></div><div>Assuming that things are kept to the 1st order features=
 (i.e. slices on one dimension, contiguous subarrays, no transpose or mirro=
r for now, etc.), it seems like the only dynamic memory necessary would be =
the pointer, and then static data as the list of extents and the list of st=
rides. &nbsp;You are right that constexpr math for the indexing can't work =
otherwise.</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_1285_14829586.1391486109124--

.

------=_Part_5444_23067884.1391501885602
Content-Type: text/plain; charset=UTF-8

It is hard to set the limit to flexibility of course. I took a quick look
at the boost thing and as so often with boost, it seems quite daunting. To
me something must be very easy to use or it won't get used.

With the new variadic templates and constexpr functionalities maybe
something more understandable can be designed.

Den tisdagen den 4:e februari 2014 kl. 04:55:09 UTC+1 skrev Jesse Perla:
>
>
> On Monday, February 3, 2014 6:13:48 PM UTC-8, Bengt Gustafsson wrote:
>>
>> I totally agree that array_view is more important, but I think there
>> should be at least one container in std for which array_view is an
>> appropriate slice. This to avoid that future numerics libraries continue
>> designing their own matrix types forever.
>>
>
> Based on my frustrating years of trying to patch together libraries, I
> fear that due to the complexity and idiosyncratic preferences for
> expression template libraries for linear algebra and tensor semantics, it
> will continue.  That said, you are right that with a basic container some
> of these other libraries could have adaptors to use them as the internal
> storage.
>
>
>> I also thought about the compile time constant array_view requirement.
>> This is rather complex as we want to support slicing of n-dimensional
>> arrays. I mean: There are so many combinations of fixed and variable.
>> Consider for instance the totally feasible case of a 3x3 subarray of any
>> larger matrix. Here both sizes
>>
> are fixed, but we need in addition store a pointer to the corner of the
>> actual data and a line stride. Now add higher ranks, transposition
>> (reordering of dimensions in the general case), mirroring and sparse
>> strides "every other data" and it really blows up in your face. Strangely
>> enough the complexity exists only when defining the slice, not when using
>> it. Then it is only a matter of multiplying each index by its own
>> precalculated coefficient and then add the start pointer. idx iteration
>> should also be quite simple.
>>
>
> I think that you were thinking a lot more functionality than I had in my
> mind.  But you are probably right, and it does need the strides.  I have
> always thought that boost::multi_array and blitz overdid it: (
> http://www.boost.org/doc/libs/1_55_0b1/libs/multi_array/doc/user.html#sec_views  and
> http://blitz.sourceforge.net/resources/blitz-0.9.pdf)
>
> Assuming that things are kept to the 1st order features (i.e. slices on
> one dimension, contiguous subarrays, no transpose or mirror for now, etc.),
> it seems like the only dynamic memory necessary would be the pointer, and
> then static data as the list of extents and the list of strides.  You are
> right that constexpr math for the indexing can't work otherwise.
>

--

---
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_5444_23067884.1391501885602
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It is hard to set the limit to flexibility of course. I to=
ok a quick look at the boost thing and as so often with boost, it seems qui=
te daunting. To me something must be very easy to use or it won't get used.=
<div><br></div><div>With the new variadic templates and constexpr functiona=
lities maybe something more understandable can be designed.<br><br>Den tisd=
agen den 4:e februari 2014 kl. 04:55:09 UTC+1 skrev Jesse Perla:<blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br>On Monday, February =
3, 2014 6:13:48 PM UTC-8, Bengt Gustafsson wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">I totally agree that array_view is more impo=
rtant, but I think there should be at least one container in std for which =
array_view is an appropriate slice. This to avoid that future numerics libr=
aries continue designing their own matrix types forever.</div></blockquote>=
<div><br></div><div>Based on my frustrating years of trying to patch togeth=
er libraries, I fear that due to the complexity and idiosyncratic preferenc=
es for expression template libraries for linear algebra and tensor semantic=
s, it will continue. &nbsp;That said, you are right that with a basic conta=
iner some of these other libraries could have adaptors to use them as the i=
nternal storage.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div>I also thought about the compile time constant ar=
ray_view requirement. This is rather complex as we want to support slicing =
of n-dimensional arrays. I mean: There are so many combinations of fixed an=
d variable. Consider for instance the totally feasible case of a 3x3 subarr=
ay of any larger matrix. Here both sizes</div></div></blockquote><blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>are fixed, but we need =
in addition store a pointer to the corner of the actual data and a line str=
ide. Now add higher ranks, transposition (reordering of dimensions in the g=
eneral case), mirroring and sparse strides "every other data" and it really=
 blows up in your face. Strangely enough the complexity exists only when de=
fining the slice, not when using it. Then it is only a matter of multiplyin=
g each index by its own precalculated coefficient and then add the start po=
inter. idx iteration should also be quite simple.</div></div></blockquote><=
div>&nbsp;</div><div>I think that you were thinking a lot more functionalit=
y than I had in my mind. &nbsp;But you are probably right, and it does need=
 the strides. &nbsp;I have always thought that boost::multi_array and blitz=
 overdid it: (<a href=3D"http://www.boost.org/doc/libs/1_55_0b1/libs/multi_=
array/doc/user.html#sec_views" target=3D"_blank" onmousedown=3D"this.href=
=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.boost.org%2Fdoc%2Flibs%2=
F1_55_0b1%2Flibs%2Fmulti_array%2Fdoc%2Fuser.html%23sec_views\46sa\75D\46snt=
z\0751\46usg\75AFQjCNFndGmJDoKdj4Kp83wnFVlfP769ow';return true;" onclick=3D=
"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.boost.org%2Fdo=
c%2Flibs%2F1_55_0b1%2Flibs%2Fmulti_array%2Fdoc%2Fuser.html%23sec_views\46sa=
\75D\46sntz\0751\46usg\75AFQjCNFndGmJDoKdj4Kp83wnFVlfP769ow';return true;">=
http://www.boost.org/doc/<wbr>libs/1_55_0b1/libs/multi_<wbr>array/doc/user.=
html#sec_views</a> &nbsp; and&nbsp;<a href=3D"http://blitz.sourceforge.net/=
resources/blitz-0.9.pdf" target=3D"_blank" onmousedown=3D"this.href=3D'http=
://www.google.com/url?q\75http%3A%2F%2Fblitz.sourceforge.net%2Fresources%2F=
blitz-0.9.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNGg19j4WcDrFkfQoF--_F1kwyii=
yw';return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75htt=
p%3A%2F%2Fblitz.sourceforge.net%2Fresources%2Fblitz-0.9.pdf\46sa\75D\46sntz=
\0751\46usg\75AFQjCNGg19j4WcDrFkfQoF--_F1kwyiiyw';return true;">http://blit=
z.sourceforge.<wbr>net/resources/blitz-0.9.pdf</a>)</div><div><br></div><di=
v>Assuming that things are kept to the 1st order features (i.e. slices on o=
ne dimension, contiguous subarrays, no transpose or mirror for now, etc.), =
it seems like the only dynamic memory necessary would be the pointer, and t=
hen static data as the list of extents and the list of strides. &nbsp;You a=
re right that constexpr math for the indexing can't work otherwise.</div></=
div></blockquote></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_5444_23067884.1391501885602--

.

------=_Part_3726_11226022.1391554015363
Content-Type: text/plain; charset=UTF-8

Upon reading the rest of the paper:

- A pity that they made the ctor from C array explicit. Otherwise this
would have been a perfect way for a function declaration to say "I want to
know the dimensions of my parameter". With explicit this becomes too
tedious at call sites.

- I am very sceptical to the subdivision between bounds and index into
different classes. Having worked for many years with an image processing
library having both a Point and a Size type I know that you often need to
use them interchangingly, breaking the "logic" of the arithmetic result
types.

- it seems that array_view and strided_array_view is a poor man's version
of the general ideas floated here.

- We surely need an operator() for n indices.

- This clearly shows that we need a way to specify that operator() takes
_exactly_ Rank indices. There was recently such a proposal on this list.
Something like int...[Rank] was to be allowed. For the time being a static
assert on sizeof...(pars) == rank will do.

I also read the boost multi-array documentation more closely and it seems
that it basically provides all the functionality I listed above, but that
usage becomes rather clumsy due to not using variadic template techniques.
Also it has no notion of compile-time fixed bounds, which to some extent
limits performance.

I seem to remember that MTL could mix fixed and variable dimensions,
although at the price of high complexity (it also predates variadic
templates).


Den tisdagen den 4:e februari 2014 kl. 09:18:05 UTC+1 skrev Bengt
Gustafsson:
>
> It is hard to set the limit to flexibility of course. I took a quick look
> at the boost thing and as so often with boost, it seems quite daunting. To
> me something must be very easy to use or it won't get used.
>
> With the new variadic templates and constexpr functionalities maybe
> something more understandable can be designed.
>
> Den tisdagen den 4:e februari 2014 kl. 04:55:09 UTC+1 skrev Jesse Perla:
>>
>>
>> On Monday, February 3, 2014 6:13:48 PM UTC-8, Bengt Gustafsson wrote:
>>>
>>> I totally agree that array_view is more important, but I think there
>>> should be at least one container in std for which array_view is an
>>> appropriate slice. This to avoid that future numerics libraries continue
>>> designing their own matrix types forever.
>>>
>>
>> Based on my frustrating years of trying to patch together libraries, I
>> fear that due to the complexity and idiosyncratic preferences for
>> expression template libraries for linear algebra and tensor semantics, it
>> will continue.  That said, you are right that with a basic container some
>> of these other libraries could have adaptors to use them as the internal
>> storage.
>>
>>
>>> I also thought about the compile time constant array_view requirement.
>>> This is rather complex as we want to support slicing of n-dimensional
>>> arrays. I mean: There are so many combinations of fixed and variable.
>>> Consider for instance the totally feasible case of a 3x3 subarray of any
>>> larger matrix. Here both sizes
>>>
>> are fixed, but we need in addition store a pointer to the corner of the
>>> actual data and a line stride. Now add higher ranks, transposition
>>> (reordering of dimensions in the general case), mirroring and sparse
>>> strides "every other data" and it really blows up in your face. Strangely
>>> enough the complexity exists only when defining the slice, not when using
>>> it. Then it is only a matter of multiplying each index by its own
>>> precalculated coefficient and then add the start pointer. idx iteration
>>> should also be quite simple.
>>>
>>
>> I think that you were thinking a lot more functionality than I had in my
>> mind.  But you are probably right, and it does need the strides.  I have
>> always thought that boost::multi_array and blitz overdid it: (
>> http://www.boost.org/doc/libs/1_55_0b1/libs/multi_array/doc/user.html#sec_views  and
>> http://blitz.sourceforge.net/resources/blitz-0.9.pdf)
>>
>> Assuming that things are kept to the 1st order features (i.e. slices on
>> one dimension, contiguous subarrays, no transpose or mirror for now, etc.),
>> it seems like the only dynamic memory necessary would be the pointer, and
>> then static data as the list of extents and the list of strides.  You are
>> right that constexpr math for the indexing can't work otherwise.
>>
>

--

---
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_3726_11226022.1391554015363
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Upon reading the rest of the paper:<div><br></div><div>- A=
 pity that they made the ctor from C array explicit. Otherwise this would h=
ave been a perfect way for a function declaration to say "I want to know th=
e dimensions of my parameter". With explicit this becomes too tedious at ca=
ll sites.</div><div><br></div><div>- I am very sceptical to the subdivision=
 between bounds and index into different classes. Having worked for many ye=
ars with an image processing library having both a Point and a Size type I =
know that you often need to use them interchangingly, breaking the "logic" =
of the arithmetic result types.</div><div><br></div><div>- it seems that ar=
ray_view and strided_array_view is a poor man's version of the general idea=
s floated here.</div><div><br></div><div>- We surely need an operator() for=
 n indices.</div><div><br></div><div>- This clearly shows that we need a wa=
y to specify that operator() takes _exactly_ Rank indices. There was recent=
ly such a proposal on this list. Something like int...[Rank] was to be allo=
wed. For the time being a static assert on sizeof...(pars) =3D=3D rank will=
 do.</div><div><br></div><div>I also read the boost multi-array documentati=
on more closely and it seems that it basically provides all the functionali=
ty I listed above, but that usage becomes rather clumsy due to not using va=
riadic template techniques. Also it has no notion of compile-time fixed bou=
nds, which to some extent limits performance.</div><div><br></div><div>I se=
em to remember that MTL could mix fixed and variable dimensions, although a=
t the price of high complexity (it also predates variadic templates).</div>=
<div><br><br>Den tisdagen den 4:e februari 2014 kl. 09:18:05 UTC+1 skrev Be=
ngt Gustafsson:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">It is hard to set the limit to flexibility of course. I took a quick look=
 at the boost thing and as so often with boost, it seems quite daunting. To=
 me something must be very easy to use or it won't get used.<div><br></div>=
<div>With the new variadic templates and constexpr functionalities maybe so=
mething more understandable can be designed.<br><br>Den tisdagen den 4:e fe=
bruari 2014 kl. 04:55:09 UTC+1 skrev Jesse Perla:<blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><br>On Monday, February 3, 2014 6:13:48 PM U=
TC-8, Bengt Gustafsson wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">I totally agree that array_view is more important, but I think t=
here should be at least one container in std for which array_view is an app=
ropriate slice. This to avoid that future numerics libraries continue desig=
ning their own matrix types forever.</div></blockquote><div><br></div><div>=
Based on my frustrating years of trying to patch together libraries, I fear=
 that due to the complexity and idiosyncratic preferences for expression te=
mplate libraries for linear algebra and tensor semantics, it will continue.=
 &nbsp;That said, you are right that with a basic container some of these o=
ther libraries could have adaptors to use them as the internal storage.</di=
v><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div>I also thought about the compile time constant array_view requirement=
.. This is rather complex as we want to support slicing of n-dimensional arr=
ays. I mean: There are so many combinations of fixed and variable. Consider=
 for instance the totally feasible case of a 3x3 subarray of any larger mat=
rix. Here both sizes</div></div></blockquote><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div>are fixed, but we need in addition store a =
pointer to the corner of the actual data and a line stride. Now add higher =
ranks, transposition (reordering of dimensions in the general case), mirror=
ing and sparse strides "every other data" and it really blows up in your fa=
ce. Strangely enough the complexity exists only when defining the slice, no=
t when using it. Then it is only a matter of multiplying each index by its =
own precalculated coefficient and then add the start pointer. idx iteration=
 should also be quite simple.</div></div></blockquote><div>&nbsp;</div><div=
>I think that you were thinking a lot more functionality than I had in my m=
ind. &nbsp;But you are probably right, and it does need the strides. &nbsp;=
I have always thought that boost::multi_array and blitz overdid it: (<a hre=
f=3D"http://www.boost.org/doc/libs/1_55_0b1/libs/multi_array/doc/user.html#=
sec_views" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\75http%3A%2F%2Fwww.boost.org%2Fdoc%2Flibs%2F1_55_0b1%2Flibs%2Fmul=
ti_array%2Fdoc%2Fuser.html%23sec_views\46sa\75D\46sntz\0751\46usg\75AFQjCNF=
ndGmJDoKdj4Kp83wnFVlfP769ow';return true;" onclick=3D"this.href=3D'http://w=
ww.google.com/url?q\75http%3A%2F%2Fwww.boost.org%2Fdoc%2Flibs%2F1_55_0b1%2F=
libs%2Fmulti_array%2Fdoc%2Fuser.html%23sec_views\46sa\75D\46sntz\0751\46usg=
\75AFQjCNFndGmJDoKdj4Kp83wnFVlfP769ow';return true;">http://www.boost.org/d=
oc/<wbr>libs/1_55_0b1/libs/multi_<wbr>array/doc/user.html#sec_views</a> &nb=
sp; and&nbsp;<a href=3D"http://blitz.sourceforge.net/resources/blitz-0.9.pd=
f" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?=
q\75http%3A%2F%2Fblitz.sourceforge.net%2Fresources%2Fblitz-0.9.pdf\46sa\75D=
\46sntz\0751\46usg\75AFQjCNGg19j4WcDrFkfQoF--_F1kwyiiyw';return true;" oncl=
ick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fblitz.source=
forge.net%2Fresources%2Fblitz-0.9.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNGg=
19j4WcDrFkfQoF--_F1kwyiiyw';return true;">http://blitz.sourceforge.<wbr>net=
/resources/blitz-0.9.pdf</a>)</div><div><br></div><div>Assuming that things=
 are kept to the 1st order features (i.e. slices on one dimension, contiguo=
us subarrays, no transpose or mirror for now, etc.), it seems like the only=
 dynamic memory necessary would be the pointer, and then static data as the=
 list of extents and the list of strides. &nbsp;You are right that constexp=
r math for the indexing can't work otherwise.</div></div></blockquote></div=
></div></blockquote></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_3726_11226022.1391554015363--

.

------=_Part_2396_8387353.1391604098509
Content-Type: text/plain; charset=UTF-8


On Tuesday, February 4, 2014 5:46:55 PM UTC-5, Bengt Gustafsson wrote:
>
>
> - This clearly shows that we need a way to specify that operator() takes
> _exactly_ Rank indices. There was recently such a proposal on this list.
> Something like int...[Rank] was to be allowed. For the time being a static
> assert on sizeof...(pars) == rank will do.
>

Agreed that fixed-size parameter packs (like 'int...[Rank]') would be a
blessing.

But even without it, there is a clean way to implement such constructors
and methods. See this SO answer:
http://stackoverflow.com/a/21355210

The thing is that it might be hard to express such a function in the
standard without going into implementation details.

--

---
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_2396_8387353.1391604098509
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Tuesday, February 4, 2014 5:46:55 PM UTC-5, Bengt G=
ustafsson wrote:<blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-lef=
t: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bord=
er-left-style: solid;" class=3D"gmail_quote"><div dir=3D"ltr"><div>&nbsp;</=
div><div>- This clearly shows that we need a way to specify that operator()=
 takes _exactly_ Rank indices. There was recently such a proposal on this l=
ist. Something like int...[Rank] was to be allowed. For the time being a st=
atic assert on sizeof...(pars) =3D=3D rank will do.</div></div></blockquote=
><div>&nbsp;</div><div>Agreed that fixed-size parameter packs (like 'int...=
[Rank]') would be a blessing.</div><div>&nbsp;</div><div>But even without i=
t, there is a clean way to implement such constructors and methods. See thi=
s SO answer:</div><div><a href=3D"http://stackoverflow.com/a/21355210">http=
://stackoverflow.com/a/21355210</a></div><div>&nbsp;</div><div>The thing is=
 that it might be hard to express such a function in the standard without g=
oing into implementation details.</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_2396_8387353.1391604098509--

.

------=_Part_960_28948364.1391605704603
Content-Type: text/plain; charset=UTF-8


On Tuesday, January 28, 2014 2:45:23 PM UTC-5, Jesse Perla wrote:
>
>
> 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!!!!
>
> I do not agree. I don't think that this class should even know what a
'row' or a 'column' is since these notions are related to matrices
(mathematical ones). An array has 'dimensions' and nothing tells if the
first/second should be interpreted as row, columns or anything else. If the
user wants to use the array_view as a row-major/column-major matrix, so be
it, as long as he manages it himself.

Of course, this array_view class could be really useful in implementing
such matrix utilities on top of it (and those utilities could introduce
those notions of row and columns). But this class (array_view) should
remain as generic as possible.

--

---
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_960_28948364.1391605704603
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Tuesday, January 28, 2014 2:45:23 PM UTC-5, Jesse P=
erla wrote:<blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1e=
x; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-le=
ft-style: solid;" class=3D"gmail_quote"><div dir=3D"ltr"><div>&nbsp;</div><=
div>From the perspective of scientific computing, the following are some co=
ncerns and additions ordered by necessity:</div><ul><li>*Deal killer* Need =
Static row vs. column major support!!!!</li></ul></div></blockquote><div>I =
do not agree. I don't think that this class&nbsp;should even know what a 'r=
ow' or a 'column' is since&nbsp;these notions are related to matrices (math=
ematical ones). An array has 'dimensions' and nothing tells if the first/se=
cond should be interpreted as row, columns or anything else. If the user wa=
nts to use the array_view as a row-major/column-major matrix, so be it, as =
long as he manages it himself.</div><div>&nbsp;</div><div>Of course, this a=
rray_view class could be really useful&nbsp;in implementing such&nbsp;matri=
x utilities on top of it (and those utilities could introduce those notions=
 of row and columns). But this class (array_view) should remain as generic =
as possible.</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_960_28948364.1391605704603--

.

------=_Part_1498_7995573.1391629075225
Content-Type: text/plain; charset=UTF-8


On Wednesday, February 5, 2014 5:08:24 AM UTC-8, Alex B wrote:
>
> I do not agree. I don't think that this class should even know what a
> 'row' or a 'column' is since these notions are related to matrices
> (mathematical ones). An array has 'dimensions' and nothing tells if the
> first/second should be interpreted as row, columns or anything else. If the
> user wants to use the array_view as a row-major/column-major matrix, so be
> it, as long as he manages it himself.
>
> Of course, this array_view class could be really useful in implementing
> such matrix utilities on top of it (and those utilities could introduce
> those notions of row and columns). But this class (array_view) should
> remain as generic as possible.
>

Absolutely, don't want to limit to any dimension but I don't think it can
avoid specifying how the data is stored. Row vs. column major storage
ordering is a generic term for N-D arrays, not for matrices (maybe there is
a better word for it, but I don't know it:
http://en.wikipedia.org/wiki/Row-major_order  The link also says which
platforms/libraries use which orderings).  I don't think we can abstract
from storage ordering if the class implements indexing and iterators as
they need to know how to jump around the memory using the strides and
pointer arithmetic in the right order.  As for genericity: I think that a
single static flag on ordering is the right way to go since it allows
static checks and tag dispatching to the right version of a library call.
 I am not sure I have seen compelling reasons for boost::multi_arrays
completely generic, dynamic storage ordering.

--

---
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_1498_7995573.1391629075225
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Wednesday, February 5, 2014 5:08:24 AM UTC-8, Alex =
B wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>=
I do not agree. I don't think that this class&nbsp;should even know what a =
'row' or a 'column' is since&nbsp;these notions are related to matrices (ma=
thematical ones). An array has 'dimensions' and nothing tells if the first/=
second should be interpreted as row, columns or anything else. If the user =
wants to use the array_view as a row-major/column-major matrix, so be it, a=
s long as he manages it himself.</div><div>&nbsp;</div><div>Of course, this=
 array_view class could be really useful&nbsp;in implementing such&nbsp;mat=
rix utilities on top of it (and those utilities could introduce those notio=
ns of row and columns). But this class (array_view) should remain as generi=
c as possible.</div></div></blockquote><div><br></div><div>Absolutely, don'=
t want to limit to any dimension but I don't think it can avoid specifying =
how the data is stored. Row vs. column major storage ordering is a generic =
term for N-D arrays, not for matrices (maybe there is a better word for it,=
 but I don't know it:&nbsp;<a href=3D"http://en.wikipedia.org/wiki/Row-majo=
r_order">http://en.wikipedia.org/wiki/Row-major_order</a>&nbsp; The link al=
so says which platforms/libraries use which orderings). &nbsp;I don't think=
 we can abstract from storage ordering if the class implements indexing and=
 iterators as they need to know how to jump around the memory using the str=
ides and pointer arithmetic in the right order. &nbsp;As for genericity: I =
think that a single static flag on ordering is the right way to go since it=
 allows static checks and tag dispatching to the right version of a library=
 call. &nbsp;I am not sure I have seen compelling reasons for boost::multi_=
arrays completely generic, dynamic storage ordering.</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_1498_7995573.1391629075225--

.

------=_Part_6854_11386857.1391629708628
Content-Type: text/plain; charset=UTF-8


On Wednesday, February 5, 2014 11:37:55 AM UTC-8, Jesse Perla wrote:
>
>
> As for genericity: I think that a single static flag on ordering is the
> right way to go since it allows static checks and tag dispatching to the
> right version of a library call.  I am not sure I have seen compelling
> reasons for boost::multi_arrays completely generic, dynamic storage
> ordering.
>

To see an example of the tag dispatching, a C++ wrapper calling LAPACK
would have dispatch to 2 versions which toggle the  LAPACK_ROW_MAJOR  vs.
LAPACK_COLUMN_MAJOR   flag when calling the routine with different
array_views:  http://www.netlib.org/lapack/lapacke.html#_array_arguments

--

---
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_6854_11386857.1391629708628
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Wednesday, February 5, 2014 11:37:55 AM UTC-8, Jess=
e Perla wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><br></div><div>As for genericity: I think that a single static flag o=
n ordering is the right way to go since it allows static checks and tag dis=
patching to the right version of a library call. &nbsp;I am not sure I have=
 seen compelling reasons for boost::multi_arrays completely generic, dynami=
c storage ordering.</div></div></blockquote><div><br></div><div>To see an e=
xample of the tag dispatching, a C++ wrapper calling LAPACK would have disp=
atch to 2 versions which toggle the &nbsp;<code style=3D"font-family: 'Cour=
ier New', Courier, monospace; font-size: medium; color: navy;">LAPACK_ROW_M=
AJOR</code><span style=3D"color: rgb(0, 0, 0); font-family: Georgia, serif;=
 font-size: medium;">&nbsp; vs.&nbsp;</span><code style=3D"font-family: 'Co=
urier New', Courier, monospace; font-size: medium; color: navy;">LAPACK_COL=
UMN_MAJOR</code><span style=3D"color: rgb(0, 0, 0); font-family: Georgia, s=
erif; font-size: medium;">&nbsp; &nbsp;</span>flag when calling the routine=
 with different array_views: &nbsp;<a href=3D"http://www.netlib.org/lapack/=
lapacke.html#_array_arguments">http://www.netlib.org/lapack/lapacke.html#_a=
rray_arguments</a>&nbsp;</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_6854_11386857.1391629708628--

.

------=_Part_5142_10267436.1391644090968
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Jesse,
Thank you very much for your encouragement and feedback!
=20

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 cases=
=20
such as transposed views (stride is decreasing) or even "self-aliasing=20
views" (stride =3D 0 in one or more dimensions).
=20
For example:

int cm_array[3 * 5] =3D {
    1, 4, 7, 10, 13,
    2, 5, 8, 11, 14,
    3, 6, 9, 12, 15
};
auto cm_sav =3D strided_array_view<int, 2>{ { 5, 3 }, { 1, 5 }, cm_array };

assert((cm_sav[{0, 0}] =3D=3D 1));
assert((cm_sav[{0, 1}] =3D=3D 2));
assert((cm_sav[{1, 0}] =3D=3D 4));
assert((cm_sav[{4, 2}] =3D=3D 15));

This of course means that it must be the *strided_array_view* type used on=
=20
interfaces expecting varying ordering. However we believe that it should be=
=20
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<T,2>=
=20
to_strided_array_view( some_column_major_math_library::matrix<T>& )".


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 and=
=20
add multi-argument operator[] directly, and we will raise this question in=
=20
Issaquah. If we had that, that would be clearly the right answer, right?

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<N>* 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?


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?
To quote the proposal: "The two-parameter constructor with the *bounds_type=
*and the=20
*Container* [...] this constructor may be used for reshaping the view with=
=20
the same or different rank".

For example:

auto view_1 =3D array_view<int, 2>{ {3, 4}, data };
auto view_2 =3D array_view<int, 2>{ {4, 3}, view_1 }; // refers to the same=
=20
"data"

The constructor checks whether the bounds size is not too large (i.e.=20
preventing from buffer overrun), however not if too small (i.e. not=20
precluding from creating a smaller sub-view).


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?


5. *Nice to have* RandomAccessContainer and other range-supported concepts,=
=20
so that existing STL and future range algorithms could be used (especially=
=20
for the 1D version)=20

I think the ranges subgroup is working on random-access range concepts, and=
=20
concepts will help with this too.


Thanks again for the valuable feedback!
=C5=81ukasz

=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_5142_10267436.1391644090968
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Jesse,</div><div>Thank you very much for your enco=
uragement and feedback!</div><div><div>&nbsp;</div><div><br></div></div><di=
v>1. <span style=3D'font-family: "Arial","sans-serif"; font-size: 10pt;'><f=
ont color=3D"#000000">*Deal
killer* Need Static Row vs. column major support!</font></span><font color=
=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font></div><div><div>&nbsp;</div></div><div>It's there -- <em>strided_arr=
ay_view</em>. We have intentionally kept the requirements&nbsp;of the provi=
ded <em>stride</em> lax to accommodate peculiar use cases such as transpose=
d views (stride is decreasing) or even "self-aliasing views" (stride =3D 0 =
in one or more dimensions).</div><div><div>&nbsp;</div></div><div>For examp=
le:</div><blockquote style=3D"margin-right: 0px;" dir=3D"ltr"><p><div><font=
 face=3D"courier new,monospace">int cm_array[3 * 5] =3D {</font></div><div>=
<font face=3D"courier new,monospace">&nbsp;&nbsp;&nbsp; 1, 4, 7, 10, 13,</f=
ont></div><div><font face=3D"courier new,monospace">&nbsp;&nbsp;&nbsp; 2, 5=
, 8, 11, 14,</font></div><div><font face=3D"courier new,monospace">&nbsp;&n=
bsp;&nbsp; 3, 6, 9, 12, 15</font></div><div><font face=3D"courier new,monos=
pace">};</font></div><div><font face=3D"courier new,monospace">auto&nbsp;cm=
_sav =3D strided_array_view&lt;int, 2&gt;{ { 5, 3 }, { 1, 5 }, cm_array };<=
/font></div><p></p><p><font face=3D"courier new,monospace">assert((cm_sav[{=
0, 0}] =3D=3D 1));</font><div><font face=3D"courier new,monospace">assert((=
cm_sav[{0, 1}] =3D=3D 2));</font></div><div><font face=3D"courier new,monos=
pace">assert((cm_sav[{1, 0}] =3D=3D 4));</font></div><div><font face=3D"cou=
rier new,monospace">assert((cm_sav[{4, 2}] =3D=3D 15));</font></div><p></p>=
</blockquote><div>This of course means that it must be&nbsp;the <em>strided=
_array_view</em> type used on interfaces expecting varying ordering. Howeve=
r we believe that it should be explicit whether the data&nbsp;can have acce=
ss pattern that is not&nbsp;"natural", due to all&nbsp;the performance impl=
ications.</div><div>I&nbsp;recognize that manually specifying the stride mi=
ght be&nbsp;error-prone, however I believe that providing&nbsp;wrappers ato=
p constructing such views would be the responsibility of the specific libra=
ry furnishing those column-major containers in the first place, e.g. "strid=
ed_array_view&lt;T,2&gt; to_strided_array_view( some_column_major_math_libr=
ary::matrix&lt;T&gt;&amp; )".</div><div><br></div><div><br></div><div>2. <s=
pan style=3D'font-family: "Arial","sans-serif"; font-size: 10pt;'><font col=
or=3D"#000000">*De</font></span><span style=3D'font-family: "Arial","sans-s=
erif"; font-size: 10pt;'><font color=3D"#000000">al killer* operator()(...)=
 support</font></span></div><div><span style=3D'font-family: "Arial","sans-=
serif"; font-size: 10pt;'><font color=3D"#000000"><br></font></span></div><=
div><span style=3D'font-family: "Arial","sans-serif"; font-size: 10pt;'><fo=
nt color=3D"#000000">Yes, we realized that operator() is the convention, th=
ough only as a workaround because C++ doesn't have multi-argument operator[=
].</font></span></div><div><span style=3D'font-family: "Arial","sans-serif"=
; font-size: 10pt;'><font color=3D"#000000">We have wrestled with whether t=
his is the right time to finally propose and add multi-argument operator[] =
directly, and we will raise this question in Issaquah. If we had that, that=
 would be clearly the right answer, right?</font></span></div><div><span st=
yle=3D'font-family: "Arial","sans-serif"; font-size: 10pt;'><font color=3D"=
#000000"><br></font></span></div><div><span style=3D'font-family: "Arial","=
sans-serif"; font-size: 10pt;'><font color=3D"#000000">In the meantime, giv=
en we abandon the pre-C++11 intuition, I find using&nbsp;<em>av[{3, 1, 4}]<=
/em> much cleaner than <em>av(3, 1, 4)</em>. To me, the message operator[] =
conveys is "accessing data structure (sub-elements)", while operator() shou=
ld always mean "executing algorithm (calling a function)". It's unfortunate=
 that we ended up with an overloaded meaning of the latter due to language =
limitations (cf. C#).&nbsp;Also,&nbsp;it only comes up when you don't alrea=
dy have an <em>index&lt;N&gt;</em> object (in which case you'd just write <=
em>av[idx]</em> and this discussion doesn't matter) but you have integer li=
terals or individual integer variables -- is that really so bad?</font></sp=
an></div><div><br></div><div>It seems like the argument is migration from e=
xisting code that happens to use operator() because that's all we had.&nbsp=
;We understand the need for migration, but if we added operator[,,], then w=
e also want to encourage new code to be written the right way going forward=
.. Is migrating from operator() syntax really a big deal? If yes, would it b=
e helpful to add a (redundant) operator() accessor that we immediately also=
 mark [[deprecated]] to discourage use?</div><div><br></div><div><br></div>=
<div>3. <span style=3D'font-family: "Arial","sans-serif"; font-size: 10pt; =
mso-fareast-font-family: Calibri; mso-fareast-theme-font: minor-latin; mso-=
ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA=
;'><font color=3D"#000000">*Would be very nice*
reshape() function</font></span></div><div><br></div><div>Can you please he=
lp me understand what part is missing here with the functionality of the&nb=
sp;<em>array_view</em> constructor?</div><div>To quote the proposal: "The t=
wo-parameter constructor with the <em>bounds_type</em> and the <em>Containe=
r</em> [...] this constructor may be used for reshaping the view with the s=
ame or different rank".</div><div><div><br></div><div>For example:<blockquo=
te style=3D"margin-right: 0px;" dir=3D"ltr"><div><font face=3D"courier new,=
monospace">auto view_1 =3D array_view&lt;int, 2&gt;{ {3, 4}, data };</font>=
</div><div><font face=3D"courier new,monospace">auto view_2 =3D array_view&=
lt;int, 2&gt;{ {4, 3}, view_1 }; // refers to the same "data"</font></div><=
/blockquote></div></div><div>The constructor checks whether the bounds size=
 is not too large (i.e. preventing from buffer overrun), however not if too=
 small (i.e. not precluding from creating a smaller sub-view).</div><div><b=
r></div><div><br></div><div>4. <span style=3D'font-family: "Arial","sans-se=
rif"; font-size: 10pt; mso-fareast-font-family: Calibri; mso-fareast-theme-=
font: minor-latin; mso-ansi-language: EN-US; mso-fareast-language: EN-US; m=
so-bidi-language: AR-SA;'><font color=3D"#000000">*Nice to have sooner
rather than later* Fixed size extents</font></span></div><div><br></div><di=
v>This is interesting, although as you observed -- it can be separated from=
 the "core" proposal into a subsequent one.</div><div>I'm also a bit worrie=
d with polluting the programming model with the concept driven mostly by th=
e optimizer rationale.</div><div>Having said that -- can you give us some s=
pecific motivating examples and data?</div><div><br></div><div><br></div><d=
iv>5.&nbsp;<span style=3D'font-family: "Arial","sans-serif"; font-size: 10p=
t;'><font color=3D"#000000">*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)</font></span><font color=3D"#000000" face=3D"Times New Roman" size=
=3D"3">

</font></div><div><br></div><div>I think the ranges subgroup is working on =
random-access range concepts, and concepts will help with this too.</div><d=
iv><br></div><div><br></div><div>Thanks again for the valuable feedback!</d=
iv><div>=C5=81ukasz</div><div><br></div><div><div>&nbsp;</div><div>On Tuesd=
ay, January 28, 2014 11:45:23 AM UTC-8, Jesse Perla wrote:</div></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-le=
ft: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bor=
der-left-style: solid;"><div dir=3D"ltr"><div>I think this is exactly the r=
ight approach for the standard. &nbsp;Instead of a container, standardize o=
n a view for contiguous or strided memory as a method for access and intero=
perability, and then use whatever containers you wish in the background. &n=
bsp;Then adaptors can be written for the various scientific and numerical l=
ibraries to take one of these objects and convert into their expression tem=
plate library. &nbsp;This may have a chance to be a standard interoperabili=
ty format, which is crucially needed for those doing numerical work. &nbsp;=
The only way to do it right now is to pass around raw pointers between disp=
arate libraries with all sorts of manual conversion in the middle.</div><di=
v><div>&nbsp;</div></div><div>As use cases for scientific programming, cons=
ider the following set of tests for adaptation:</div><div><ol><li>Adaptor w=
ritten which can "convert" this 1D version of boost::ublas vector, and 2D o=
f ublas::matrix, COIN-OR dense matrix and vector, Python Numpy vector/matri=
x in C++ libraries, and matlab MEX extension<div>&nbsp;</div></li><li>Can a=
n 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): <a onmousedown=3D"this.href=3D'https://www.google.=
com/url?q\75https%3A%2F%2Fsvn.boost.org%2Fsvn%2Fboost%2Fsandbox%2Fnumeric_b=
indings%2Fboost%2Fnumeric%2Fbindings%2F\46sa\75D\46sntz\0751\46usg\75AFQjCN=
FhNKBTnvDMHUmGVfcgXpWX0J7Mnw';return true;" onclick=3D"this.href=3D'https:/=
/www.google.com/url?q\75https%3A%2F%2Fsvn.boost.org%2Fsvn%2Fboost%2Fsandbox=
%2Fnumeric_bindings%2Fboost%2Fnumeric%2Fbindings%2F\46sa\75D\46sntz\0751\46=
usg\75AFQjCNFhNKBTnvDMHUmGVfcgXpWX0J7Mnw';return true;" href=3D"https://svn=
..boost.org/svn/boost/sandbox/numeric_bindings/boost/numeric/bindings/" targ=
et=3D"_blank">https://svn.boost.org/svn/<wbr>boost/sandbox/numeric_<wbr>bin=
dings/boost/numeric/<wbr>bindings/</a>. &nbsp;To see if the correct accesso=
rs/types are in array_view, check out the example adaptor implementations i=
n <a onmousedown=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F=
%2Fsvn.boost.org%2Fsvn%2Fboost%2Fsandbox%2Fnumeric_bindings%2Fboost%2Fnumer=
ic%2Fbindings%2Fboost%2Fmulti_array.hpp\46sa\75D\46sntz\0751\46usg\75AFQjCN=
GQAR7YmaGZC7_Mvi8rVXkNhKYt4w';return true;" onclick=3D"this.href=3D'https:/=
/www.google.com/url?q\75https%3A%2F%2Fsvn.boost.org%2Fsvn%2Fboost%2Fsandbox=
%2Fnumeric_bindings%2Fboost%2Fnumeric%2Fbindings%2Fboost%2Fmulti_array.hpp\=
46sa\75D\46sntz\0751\46usg\75AFQjCNGQAR7YmaGZC7_Mvi8rVXkNhKYt4w';return tru=
e;" href=3D"https://svn.boost.org/svn/boost/sandbox/numeric_bindings/boost/=
numeric/bindings/boost/multi_array.hpp" target=3D"_blank">https://svn.boost=
..org/svn/<wbr>boost/sandbox/numeric_<wbr>bindings/boost/numeric/<wbr>bindin=
gs/boost/multi_array.hpp</a> and <a onmousedown=3D"this.href=3D'https://www=
..google.com/url?q\75https%3A%2F%2Fsvn.boost.org%2Fsvn%2Fboost%2Fsandbox%2Fn=
umeric_bindings%2Fboost%2Fnumeric%2Fbindings%2Feigen%2Fmatrix.hpp\46sa\75D\=
46sntz\0751\46usg\75AFQjCNGDoUYcES8xClzou_kVsLYwCFvzsA';return true;" oncli=
ck=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fsvn.boost.o=
rg%2Fsvn%2Fboost%2Fsandbox%2Fnumeric_bindings%2Fboost%2Fnumeric%2Fbindings%=
2Feigen%2Fmatrix.hpp\46sa\75D\46sntz\0751\46usg\75AFQjCNGDoUYcES8xClzou_kVs=
LYwCFvzsA';return true;" href=3D"https://svn.boost.org/svn/boost/sandbox/nu=
meric_bindings/boost/numeric/bindings/eigen/matrix.hpp" target=3D"_blank">h=
ttps://svn.boost.org/svn/<wbr>boost/sandbox/numeric_<wbr>bindings/boost/num=
eric/<wbr>bindings/eigen/matrix.hpp</a>. &nbsp;One requirement of this woul=
d be that the adaptor class should have no storage of its own.<div>&nbsp;</=
div></li></ol></div><div><div>&nbsp;</div></div><div><div>&nbsp;</div></div=
><div>From the perspective of scientific computing, the following are some =
concerns and additions ordered by necessity:</div><div><ul><li>*Deal killer=
* Need Static row vs. column major support!!!!</li><ul><li>A large number o=
f scientific libraries are written with column major data. &nbsp;This is es=
pecially true when calling high performance libraries written in fortran, o=
r interfacing with matlab in MEX. &nbsp;EVERY major container used for nume=
rical analysis has this option.</li><li>boost::multi_array allows a runtime=
 specification for the ordering, but this is overkill. &nbsp;Better is a te=
mplate parameter which determines the ordering for every dimension, and whi=
ch can be queried by TMP used in the adaptors. &nbsp;Check out the ordering=
_type in boost::ublas, &nbsp;ColMajor vs. RowMajor in eigen, and the genera=
l_storage_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 row-major, then just a static_assert to reject.</li><li>I don't see h=
ow this could be added later without breaking a bunch of generic code. &nbs=
p;I also can't stress enough how crucial this is, or it is pretty much usel=
ess for interoperability (and, if you ask me, doesn't even belong in a C++ =
standard as it only creates more implementation noise)</li></ul></ul></div>=
<div><ul><li>*Deal killer* operator()(...) support</li><ul><li>A good porti=
on of generic code is written with operator(), especially using 2D speciali=
zations. &nbsp;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. &nbsp;operator() code is much more prevalent her=
e than operator []</li><li>This should be a variadic accessor for a list of=
 extents, and doesn't need to have an index_type version. &nbsp;Having a co=
nstexpr specialization would also be nice and allow optimizations, but is n=
ot necessary.</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></div><div><ul><li>*Would be very nice* reshape() function</li><ul><li>=
It would be nice for the user to be able to reshape the array with the same=
 allocated size. &nbsp;Not resize! &nbsp;An assert could ensure that the si=
ze remains the same.</li><li>This is very nice for in-place algorithms usin=
g huge array's where the user doesn't want to, or doesn't have the resource=
s to, reallocate 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></di=
v><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 variad=
ic template argument. &nbsp;Would not support a reshape() function as that =
would be a different type. &nbsp;Though a conversion function could be writ=
ten.</li><li>This enables a huge number of optimizations and compile time e=
xtent checking for errors. &nbsp;Since most of the 1 and 2d array libraries=
 have this, we would be able to pass it around and adapt as required when u=
sing those algorithms (also SIMD based optimizations)</li></ul></ul></div><=
div><ul><li>*Nice to have* RandomAccessContainer and other range-supported =
concepts, so that existing STL and future range algorithms could be used (e=
specially for the 1D version)<div>&nbsp;</div></li></ul></div><div><div>&nb=
sp;</div></div></div></blockquote></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_5142_10267436.1391644090968--

.

------=_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<T,2>=
=20
> to_strided_array_view( some_column_major_math_library::matrix<T>& )".
>

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<N>* 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

<div dir=3D"ltr">Thanks, we all really appreciate this work.<br><br>On Wedn=
esday, February 5, 2014 3:48:10 PM UTC-8, =C5=81ukasz Mendakiewicz wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">1. <span style=
=3D"font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;font-size:10pt"><f=
ont color=3D"#000000">*Deal
killer* Need Static Row vs. column major support!</font></span><font color=
=3D"#000000" size=3D"3" face=3D"Times New Roman">

</font><div><div>&nbsp;</div></div><div>It's there -- <i>strided_array_view=
</i>. We have intentionally kept the requirements&nbsp;of the provided <i>s=
tride</i> 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).</div><br><div>This of course means that it must be&nbsp;t=
he <i>strided_array_view</i> type used on interfaces expecting varying orde=
ring. However we believe that it should be explicit whether the data&nbsp;c=
an have access pattern that is not&nbsp;"natural", due to all&nbsp;the perf=
ormance implications.</div><div>I&nbsp;recognize that manually specifying t=
he stride might be&nbsp;error-prone, however I believe that providing&nbsp;=
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&lt;T,2&gt; to_strided_array_view( some_column_maj=
or_math_<wbr>library::matrix&lt;T&gt;&amp; )".</div></div></blockquote><div=
><br>My answer:<br>Ah, I didn't see that.&nbsp; That does it for dynamic or=
derings like boost::multi_array has.&nbsp; My only problem then is that the=
re is no way to have a static check on the orderings.&nbsp; 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.&nbsp; I also can't tag dispatch =
to different library functions based on the storage order.<br>&nbsp;</div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div=
><div>2. <span style=3D"font-family:&quot;Arial&quot;,&quot;sans-serif&quot=
;;font-size:10pt"><font color=3D"#000000">*De</font></span><span style=3D"f=
ont-family:&quot;Arial&quot;,&quot;sans-serif&quot;;font-size:10pt"><font c=
olor=3D"#000000">al killer* operator()(...) support</font></span></div><div=
><span style=3D"font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;font-s=
ize:10pt"><font color=3D"#000000"><br></font></span></div><div><span style=
=3D"font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;font-size:10pt"><f=
ont color=3D"#000000">Yes, we realized that operator() is the convention, t=
hough only as a workaround because C++ doesn't have multi-argument operator=
[].</font></span></div><div><span style=3D"font-family:&quot;Arial&quot;,&q=
uot;sans-serif&quot;;font-size:10pt"><font color=3D"#000000">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?</font></span></=
div></div></blockquote><div dir=3D"ltr">My answer:<br>For me, the issue is =
more one of interoperability in making existing code generic.&nbsp; 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).&nbsp; So it makes converting that code t=
o use a generic array_view interface very costly.<br>&nbsp;<span style=3D"f=
ont-family:&quot;Arial&quot;,&quot;sans-serif&quot;;font-size:10pt"><font c=
olor=3D"#000000"><br>In the meantime, given we abandon the pre-C++11 intuit=
ion, I find using&nbsp;<i>av[{3, 1, 4}]</i> much cleaner than <i>av(3, 1, 4=
)</i>. 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#).&nbsp;Also,&nbsp;=
it only comes up when you don't already have an <i>index&lt;N&gt;</i> objec=
t (in which case you'd just write <i>av[idx]</i> and this discussion doesn'=
t matter) but you have integer literals or individual integer variables -- =
is that really so bad?</font></span><div>It seems like the argument is migr=
ation from existing code that happens to use operator() because that's all =
we had.&nbsp;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?<br><br><br></div></div>=
<div>My answer:<br>In this case, I think it is pretty bad and could hamstri=
ng the interface.&nbsp; 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.&nbsp; 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.&nbsp; A [[deprecated]] doesn't hurt (a=
s long as you never actually deprecate it).&nbsp; This just doesn't seem li=
ke a battle worth fighting over aesthetics to me.<br><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><div>3. <s=
pan style=3D"font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;font-size=
:10pt"><font color=3D"#000000">*Would be very nice*
reshape() function</font></span></div><div><br></div><div>Can you please he=
lp me understand what part is missing here with the functionality of the&nb=
sp;<i>array_view</i> constructor?</div></div></blockquote><div>You are righ=
t, that is enough.<br>&nbsp;<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><div><br></div><div><br></div><div>4. <span style=
=3D"font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;font-size:10pt"><f=
ont color=3D"#000000">*Nice to have sooner
rather than later* Fixed size extents</font></span></div><div><br></div><di=
v>This is interesting, although as you observed -- it can be separated from=
 the "core" proposal into a subsequent one.</div><div>I'm also a bit worrie=
d with polluting the programming model with the concept driven mostly by th=
e optimizer rationale.</div><div>Having said that -- can you give us some s=
pecific motivating examples and data?</div></div></blockquote><div dir=3D"l=
tr"><br>To me, the biggest motivating examples for this are ensuring adapta=
bility and ensuring conformance for tensor/matrix operations.<br><br><b>For=
 optimization: </b>Includes things like SIMD due to fixed extents, managing=
 cache boundaries, etc. that I don't really understand.&nbsp; I also know t=
hat this becomes extremely important for geometry.&nbsp; 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).&nbsp; Think through inverti=
ng a matrix&nbsp; if you know it is 2x2 at compiletime and can dispatch to =
the closed form solution.&nbsp; They will handcraft assembler code to use S=
SE instructions for things like inner product if they know it fits in the r=
egister.&nbsp; 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.<br><b=
>For interoperability:</b> The ideal here would be that I can take an array=
_view and create adaptor to eigen/ublas/etc.&nbsp; then use their expressio=
n templates for the sematics.&nbsp; But to generate a static eigen vector/m=
atrix, I need to statically query the bounds of the array_view.<br><b>For c=
onformance: </b>Having static sizes can significantly improve correctness i=
n generic code at compiletime.&nbsp; For example, making sure that an inner=
 product of two 1D slices have the same length at compile time, etc.<div><b=
r></div><br><div><br></div><div><div>&nbsp;</div><div>On Tuesday, January 2=
8, 2014 11:45:23 AM UTC-8, Jesse Perla wrote:</div></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-=
left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">=
<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><div>&nbsp;</div></div=
><div>As use cases for scientific programming, consider the following set o=
f tests for adaptation:</div><div><ol><li>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<div>&nbsp;</div></li><li>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):=
 <a href=3D"https://svn.boost.org/svn/boost/sandbox/numeric_bindings/boost/=
numeric/bindings/" target=3D"_blank" onmousedown=3D"this.href=3D'https://ww=
w.google.com/url?q\75https%3A%2F%2Fsvn.boost.org%2Fsvn%2Fboost%2Fsandbox%2F=
numeric_bindings%2Fboost%2Fnumeric%2Fbindings%2F\46sa\75D\46sntz\0751\46usg=
\75AFQjCNFhNKBTnvDMHUmGVfcgXpWX0J7Mnw';return true;" onclick=3D"this.href=
=3D'https://www.google.com/url?q\75https%3A%2F%2Fsvn.boost.org%2Fsvn%2Fboos=
t%2Fsandbox%2Fnumeric_bindings%2Fboost%2Fnumeric%2Fbindings%2F\46sa\75D\46s=
ntz\0751\46usg\75AFQjCNFhNKBTnvDMHUmGVfcgXpWX0J7Mnw';return true;">https://=
svn.boost.org/svn/<wbr>boost/sandbox/numeric_<wbr>bindings/boost/numeric/<w=
br>bindings/</a>. &nbsp;To see if the correct accessors/types are in array_=
view, check out the example adaptor implementations in <a href=3D"https://s=
vn.boost.org/svn/boost/sandbox/numeric_bindings/boost/numeric/bindings/boos=
t/multi_array.hpp" target=3D"_blank" onmousedown=3D"this.href=3D'https://ww=
w.google.com/url?q\75https%3A%2F%2Fsvn.boost.org%2Fsvn%2Fboost%2Fsandbox%2F=
numeric_bindings%2Fboost%2Fnumeric%2Fbindings%2Fboost%2Fmulti_array.hpp\46s=
a\75D\46sntz\0751\46usg\75AFQjCNGQAR7YmaGZC7_Mvi8rVXkNhKYt4w';return true;"=
 onclick=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fsvn.b=
oost.org%2Fsvn%2Fboost%2Fsandbox%2Fnumeric_bindings%2Fboost%2Fnumeric%2Fbin=
dings%2Fboost%2Fmulti_array.hpp\46sa\75D\46sntz\0751\46usg\75AFQjCNGQAR7Yma=
GZC7_Mvi8rVXkNhKYt4w';return true;">https://svn.boost.org/svn/<wbr>boost/sa=
ndbox/numeric_<wbr>bindings/boost/numeric/<wbr>bindings/boost/multi_array.h=
pp</a> and <a href=3D"https://svn.boost.org/svn/boost/sandbox/numeric_bindi=
ngs/boost/numeric/bindings/eigen/matrix.hpp" target=3D"_blank" onmousedown=
=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fsvn.boost.org=
%2Fsvn%2Fboost%2Fsandbox%2Fnumeric_bindings%2Fboost%2Fnumeric%2Fbindings%2F=
eigen%2Fmatrix.hpp\46sa\75D\46sntz\0751\46usg\75AFQjCNGDoUYcES8xClzou_kVsLY=
wCFvzsA';return true;" onclick=3D"this.href=3D'https://www.google.com/url?q=
\75https%3A%2F%2Fsvn.boost.org%2Fsvn%2Fboost%2Fsandbox%2Fnumeric_bindings%2=
Fboost%2Fnumeric%2Fbindings%2Feigen%2Fmatrix.hpp\46sa\75D\46sntz\0751\46usg=
\75AFQjCNGDoUYcES8xClzou_kVsLYwCFvzsA';return true;">https://svn.boost.org/=
svn/<wbr>boost/sandbox/numeric_<wbr>bindings/boost/numeric/<wbr>bindings/ei=
gen/matrix.hpp</a>. &nbsp;One requirement of this would be that the adaptor=
 class should have no storage of its own.<div>&nbsp;</div></li></ol></div><=
div><div>&nbsp;</div></div><div><div>&nbsp;</div></div><div>From the perspe=
ctive of scientific computing, the following are some concerns and addition=
s ordered by necessity:</div><div><ul><li>*Deal killer* Need Static row vs.=
 column major support!!!!</li><ul><li>A large number of scientific librarie=
s are written with column major data. &nbsp;This is especially true when ca=
lling high performance libraries written in fortran, or interfacing with ma=
tlab in MEX. &nbsp;EVERY major container used for numerical analysis has th=
is option.</li><li>boost::multi_array allows a runtime specification for th=
e ordering, but this is overkill. &nbsp;Better is a template parameter whic=
h determines the ordering for every dimension, and which can be queried by =
TMP used in the adaptors. &nbsp;Check out the ordering_type in boost::ublas=
, &nbsp;ColMajor vs. RowMajor in eigen, and the general_storage_order in bo=
ost::multi_array and seimilar ones in GLAS, MTL, etc.</li><li>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.</li><li>I don't see how this could be adde=
d later without breaking a bunch of generic code. &nbsp;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)</li></ul></ul></div><div><ul><li>*Deal ki=
ller* operator()(...) support</li><ul><li>A good portion of generic code is=
 written with operator(), especially using 2D specializations. &nbsp;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. &nbsp;operator() code is much more prevalent here than operator []</l=
i><li>This should be a variadic accessor for a list of extents, and doesn't=
 need to have an index_type version. &nbsp;Having a constexpr specializatio=
n would also be nice and allow optimizations, but is not necessary.</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></div><div><ul><l=
i>*Would be very nice* reshape() function</li><ul><li>It would be nice for =
the user to be able to reshape the array with the same allocated size. &nbs=
p;Not resize! &nbsp;An assert could ensure that the size remains 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, reallocate an e=
ntire copy (e.g. transpose)</li><li>It also comes up a lot in numeric analy=
sis with tensor products and multivariate regressions. &nbsp;(e.g. using th=
e 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_ar=
ray_view: Pass in a static list of extents as a variadic template argument.=
 &nbsp;Would not support a reshape() function as that would be a different =
type. &nbsp;Though a conversion function could be written.</li><li>This ena=
bles a huge number of optimizations and compile time extent checking for er=
rors. &nbsp;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)</li></ul></ul></div><div><ul><li>*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)<div>&nbsp;</div></li></ul></div><div><div>&nbsp;</div></div></div>=
</blockquote></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_7155_10483635.1391646242555--

.

------=_Part_472_32734932.1391706542581
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I would also say that allowing a fixed size in any or all dimensions would=
=20
be a big improvement, now libraries will automatically improve performance=
=20
if made generic.

My idea on how to define this in the interface is that the array_view has=
=20
each size as a variadic int template parameter, with 0 (or maybe -1) as a=
=20
placeholder for variable dimensions. 0 would be more beautiful but it goes=
=20
against my other proposal to allow 0 size arrays to some extent. -1 is=20
safer and a constant can of course be set to -1:


static const int vsize =3D -1;

template<typename T, int... sizes> class array_view {
};

The constructor would of course need as many size numbers as there are=20
vsize dimensions.

Implementationwise I think this can readily be implemented with a recursive=
=20
helper template that calculates strides, and the number of vsize entries.=
=20
It would use the classic head/tail idiom and be specialized if the head is=
=20
vsize.

Now, the next thing to note is that for this to actually create speedups=20
the size query methods must selectively be constexpr depending on if that=
=20
particular dimension is fixed. Thus it does not work with a "int=20
getsize(int dim);" api or one that returns a bounds object. Instead we need=
=20
a:

template<int dim> int getsize();

This somehow gets specialized as a constexpr method for fixed dimensions.

This is of course not compatible with any preexisting libraries out there,=
=20
but then again, I don't think there is any consensus about what these=20
methods should be called anyway, so most libraries would have to be updated=
=20
whatever name we choose.

Combining this functionality with transpose etc. may be very tricky.

Maybe we could ignore the rather few cases where some dimensions are fixed=
=20
and some not, although there are of course lots of such cases. But we must=
=20
put a limit somewhere, and I think that fully fixed or fully dynamic covers=
=20
most uses.

On the other hand, with my way of defining fixed vs dynamic it could be a=
=20
QoI question whether the getsize() method really changes to constexpr or=20
not.

I would love to try to write such a array_view (and matrix) class but I am=
=20
short of time right now.

When it comes to allowing operator[] with multiple arguments I think it=20
should be done. Obviously very few instances of actually using a classic=20
comma expression in a [] exist out there. And the only thing that would=20
happen would be that these now generate an error message as there is no 2-d=
=20
operator[] in the old code (after all, it wasn't allowed). So there is no=
=20
scary silent change of behaviour, only loud errors in very rare cases.

The deal killer with () support may not be so awful in that case, as the=20
missing operator() will also cause noise while compiling and the getsize()=
=20
issue needs to be handled anyway, which is probably almost as many=20
callsites as operator(). I think it would be a real pity to introduce=20
multidim operator[] AND array_view WITHOUT forcing the templating of=20
libraries to include changing to []. This is a chance to get it done that=
=20
never will come back!

Finally, it seems more and more that array_view is more of a concept than=
=20
an actual class. That is, it will act as a model for other classes in the=
=20
future, which will be designed to work with those templated algorithms.=20
This could include for instance dialognal, triangular, banded and sparse=20
matrices and views thereof. With this in the back of our heads it becomes=
=20
even more important that the getsize() method is templated on the dimension=
=20
to allow the _concept_ to include, at least, compatible classes to have=20
some dimensions of fixed size, some variable.

I have also been writing a bit in the "2d drawing" thread, and there is=20
need for 2D points as well as 2x3 affine transform matrices. If only=20
dynamically sized matrices and views are available they will not be used=20
for this type of purposes, both for performance reasons and as it is=20
awkward to have to check the size of the incoming data every time.

As a side note I suggested a system similar to begin() and end() to be able=
=20
to accomodate any old "point" and "rect" classes such as those of MFC, Qt=
=20
or whatever with the drawing library:

template <typename POINT> struct point_adapter {
    decltype(POINT::x) getx(const POINT& p) { return p.x; }
.... same for y etc.
};

Then if you don't have x and y members in your point you can specialize=20
this adapter. [which could be replaced by free functions getx and gety if=
=20
desired].

Maybe we should have something similar for array dimensions? That would=20
potentially allow matrices from different libraries to interoperate without=
=20
creating intermediate array_view objects (unless we want to slice matrix to=
=20
a smaller size). On the other hand the code of the (now) templated=20
functionality would be less readable, especially the indexing operator:

template<typename ARRAY, typename... Ts> int acess(ARRAY& arr, Ts... ixes) =
{
    // Default implementation uses operator():
    return arr(ixes...);
};

// An advantage is of course that with some recursive template trickery=20
this can be specialized for multidimensional C arrays even.

But as said, having to write access(matrix, r, k) all the time is no fun, I=
=20
guess.

Den torsdagen den 6:e februari 2014 kl. 01:24:02 UTC+1 skrev Jesse Perla:
>
> Thanks, we all really appreciate this work.
>
> On Wednesday, February 5, 2014 3:48:10 PM UTC-8, =C5=81ukasz Mendakiewicz=
 wrote:
>>
>> 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 sho=
uld=20
>> be explicit whether the data can have access pattern that is not "natura=
l",=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<T,2=
>=20
>> to_strided_array_view( some_column_major_math_library::matrix<T>& )".
>>
>
> 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, ubla=
s,=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 quest=
ion=20
>> in Issaquah. If we had that, that would be clearly the right answer, rig=
ht?
>>
> 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 bee=
n=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<N>* object (in which case you'd just write=20
> *av[idx]* and this discussion doesn't matter) but you have integer=20
> literals or individual integer variables -- is that really so bad?
> It seems like the argument is migration from existing code that happens t=
o=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 n=
ew=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 the=
re=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 interfac=
es=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 fro=
m=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 an=
d=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=20
> the fixed sizes are all over the place).  Think through inverting a matri=
x =20
> if 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 o=
f=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 tha=
t=20
> an inner product of two 1D slices have the same length at compile time, e=
tc.
>
>
>
> =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=
=20
>> a 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 variou=
s=20
>> scientific and numerical libraries to take one of these objects and conv=
ert=20
>> into their expression template library.  This may have a chance to be a=
=20
>> standard interoperability format, which is crucially needed for those do=
ing=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=20
>>    boost::ublas vector, and 2D of ublas::matrix, COIN-OR dense matrix an=
d=20
>>    vector, Python Numpy vector/matrix in C++ libraries, and matlab MEX=
=20
>>    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/numeri=
c/bindings/.=20
>>     To see if the correct accessors/types are in array_view, check out t=
he=20
>>    example adaptor implementations in=20
>>    https://svn.boost.org/svn/boost/sandbox/numeric_bindings/boost/numeri=
c/bindings/boost/multi_array.hppand=20
>>    https://svn.boost.org/svn/boost/sandbox/numeric_bindings/boost/numeri=
c/bindings/eigen/matrix.hpp.=20
>>     One requirement of this would be that the adaptor class should have =
no=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.  =
EVERY=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 wh=
ich=20
>>       determines the ordering for every dimension, and which can be quer=
ied by=20
>>       TMP used in the adaptors.  Check out the ordering_type in boost::u=
blas,=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 thi=
s 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 implementati=
on 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 cod=
e 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 =
not=20
>>       necessary.
>>       - Examples: ublas, eigen, COIN-OR densematrix, and most others=20
>>       have 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 w=
ith 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() functio=
n as that=20
>>       would be a different type.  Though a conversion function could be =
written.
>>       - This enables a huge number of optimizations and compile time=20
>>       extent checking for errors.  Since most of the 1 and 2d array libr=
aries=20
>>       have this, we would be able to pass it around and adapt as require=
d 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 u=
sed=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_472_32734932.1391706542581
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I would also say that allowing a fixed size in any or all =
dimensions would be a big improvement, now libraries will automatically imp=
rove performance if made generic.<div><br></div><div>My idea on how to defi=
ne this in the interface is that the array_view has each size as a variadic=
 int template parameter, with 0 (or maybe -1) as a placeholder for variable=
 dimensions. 0 would be more beautiful but it goes against my other proposa=
l to allow 0 size arrays to some extent. -1 is safer and a constant can of =
course be set to -1:</div><div><br></div><div><br></div><div>static const i=
nt vsize =3D -1;</div><div><br></div><div>template&lt;typename T, int... si=
zes&gt; class array_view {</div><div>};</div><div><br></div><div>The constr=
uctor would of course need as many size numbers as there are vsize dimensio=
ns.</div><div><br></div><div>Implementationwise I think this can readily be=
 implemented with a recursive helper template that calculates strides, and =
the number of vsize entries. It would use the classic head/tail idiom and b=
e specialized if the head is vsize.</div><div><br></div><div>Now, the next =
thing to note is that for this to actually create speedups the size query m=
ethods must selectively be constexpr depending on if that particular dimens=
ion is fixed. Thus it does not work with a "int getsize(int dim);" api or o=
ne that returns a bounds object. Instead we need a:</div><div><br></div><di=
v>template&lt;int dim&gt; int getsize();</div><div><br></div><div>This some=
how gets specialized as a constexpr method for fixed dimensions.</div><div>=
<br></div><div>This is of course not compatible with any preexisting librar=
ies out there, but then again, I don't think there is any consensus about w=
hat these methods should be called anyway, so most libraries would have to =
be updated whatever name we choose.</div><div><br></div><div>Combining this=
 functionality with transpose etc. may be very tricky.</div><div><br></div>=
<div>Maybe we could ignore the rather few cases where some dimensions are f=
ixed and some not, although there are of course lots of such cases. But we =
must put a limit somewhere, and I think that fully fixed or fully dynamic c=
overs most uses.</div><div><br></div><div>On the other hand, with my way of=
 defining fixed vs dynamic it could be a QoI question whether the getsize()=
 method really changes to constexpr or not.</div><div><br></div><div>I woul=
d love to try to write such a array_view (and matrix) class but I am short =
of time right now.</div><div><br></div><div>When it comes to allowing opera=
tor[] with multiple arguments I think it should be done. Obviously very few=
 instances of actually using a classic comma expression in a [] exist out t=
here. And the only thing that would happen would be that these now generate=
 an error message as there is no 2-d operator[] in the old code (after all,=
 it wasn't allowed). So there is no scary silent change of behaviour, only =
loud errors in very rare cases.</div><div><br></div><div>The deal killer wi=
th () support may not be so awful in that case, as the missing operator() w=
ill also cause noise while compiling and the getsize() issue needs to be ha=
ndled anyway, which is probably almost as many callsites as operator(). I t=
hink it would be a real pity to introduce multidim operator[] AND array_vie=
w WITHOUT forcing the templating of libraries to include changing to []. Th=
is is a chance to get it done that never will come back!</div><div><br></di=
v><div>Finally, it seems more and more that array_view is more of a concept=
 than an actual class. That is, it will act as a model for other classes in=
 the future, which will be designed to work with those templated algorithms=
.. This could include for instance dialognal, triangular, banded and sparse =
matrices and views thereof. With this in the back of our heads it becomes e=
ven more important that the getsize() method is templated on the dimension =
to allow the _concept_ to include, at least, compatible classes to have som=
e dimensions of fixed size, some variable.</div><div><br></div><div>I have =
also been writing a bit in the "2d drawing" thread, and there is need for 2=
D points as well as 2x3 affine transform matrices. If only dynamically size=
d matrices and views are available they will not be used for this type of p=
urposes, both for performance reasons and as it is awkward to have to check=
 the size of the incoming data every time.</div><div><br></div><div>As a si=
de note I suggested a system similar to begin() and end() to be able to acc=
omodate any old "point" and "rect" classes such as those of MFC, Qt or what=
ever with the drawing library:</div><div><br></div><div>template &lt;typena=
me POINT&gt; struct point_adapter {</div><div>&nbsp; &nbsp; decltype(POINT:=
:x) getx(const POINT&amp; p) { return p.x; }</div><div>... same for y etc.<=
/div><div>};</div><div><br></div><div>Then if you don't have x and y member=
s in your point you can specialize this adapter. [which could be replaced b=
y free functions getx and gety if desired].</div><div><br></div><div>Maybe =
we should have something similar for array dimensions? That would potential=
ly allow matrices from different libraries to interoperate without creating=
 intermediate array_view objects (unless we want to slice matrix to a small=
er size). On the other hand the code of the (now) templated functionality w=
ould be less readable, especially the indexing operator:</div><div><br></di=
v><div>template&lt;typename ARRAY, typename... Ts&gt; int acess(ARRAY&amp; =
arr, Ts... ixes) {</div><div>&nbsp; &nbsp; // Default implementation uses o=
perator():</div><div>&nbsp; &nbsp; return arr(ixes...);</div><div>};</div><=
div><br></div><div>// An advantage is of course that with some recursive te=
mplate trickery this can be specialized for multidimensional C arrays even.=
</div><div><br></div><div>But as said, having to write access(matrix, r, k)=
 all the time is no fun, I guess.</div><div><br>Den torsdagen den 6:e febru=
ari 2014 kl. 01:24:02 UTC+1 skrev Jesse Perla:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr">Thanks, we all really appreciate this work=
..<br><br>On Wednesday, February 5, 2014 3:48:10 PM UTC-8, =C5=81ukasz Menda=
kiewicz wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">1. <=
span style=3D"font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;font-siz=
e:10pt"><font color=3D"#000000">*Deal
killer* Need Static Row vs. column major support!</font></span><font color=
=3D"#000000" size=3D"3" face=3D"Times New Roman">

</font><div><div>&nbsp;</div></div><div>It's there -- <i>strided_array_view=
</i>. We have intentionally kept the requirements&nbsp;of the provided <i>s=
tride</i> 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).</div><br><div>This of course means that it must be&nbsp;t=
he <i>strided_array_view</i> type used on interfaces expecting varying orde=
ring. However we believe that it should be explicit whether the data&nbsp;c=
an have access pattern that is not&nbsp;"natural", due to all&nbsp;the perf=
ormance implications.</div><div>I&nbsp;recognize that manually specifying t=
he stride might be&nbsp;error-prone, however I believe that providing&nbsp;=
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&lt;T,2&gt; to_strided_array_view( some_column_maj=
or_math_<wbr>library::matrix&lt;T&gt;&amp; )".</div></div></blockquote><div=
><br>My answer:<br>Ah, I didn't see that.&nbsp; That does it for dynamic or=
derings like boost::multi_array has.&nbsp; My only problem then is that the=
re is no way to have a static check on the orderings.&nbsp; 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.&nbsp; I also can't tag dispatch =
to different library functions based on the storage order.<br>&nbsp;</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div=
>2. <span style=3D"font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;fon=
t-size:10pt"><font color=3D"#000000">*De</font></span><span style=3D"font-f=
amily:&quot;Arial&quot;,&quot;sans-serif&quot;;font-size:10pt"><font color=
=3D"#000000">al killer* operator()(...) support</font></span></div><div><sp=
an style=3D"font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;font-size:=
10pt"><font color=3D"#000000"><br></font></span></div><div><span style=3D"f=
ont-family:&quot;Arial&quot;,&quot;sans-serif&quot;;font-size:10pt"><font c=
olor=3D"#000000">Yes, we realized that operator() is the convention, though=
 only as a workaround because C++ doesn't have multi-argument operator[].</=
font></span></div><div><span style=3D"font-family:&quot;Arial&quot;,&quot;s=
ans-serif&quot;;font-size:10pt"><font color=3D"#000000">We have wrestled wi=
th whether this is the right time to finally propose and add multi-argument=
 operator[] directly, and we will raise this question in Issaquah. If we ha=
d that, that would be clearly the right answer, right?</font></span></div><=
/div></blockquote><div dir=3D"ltr">My answer:<br>For me, the issue is more =
one of interoperability in making existing code generic.&nbsp; An enormous =
amount of software for 2D and 3D containers has been written with operator(=
) because a multi-argument operator[] didn't exist (see all of the librarie=
s I mentioned and many more).&nbsp; So it makes converting that code to use=
 a generic array_view interface very costly.<br>&nbsp;<span style=3D"font-f=
amily:&quot;Arial&quot;,&quot;sans-serif&quot;;font-size:10pt"><font color=
=3D"#000000"><br>In the meantime, given we abandon the pre-C++11 intuition,=
 I find using&nbsp;<i>av[{3, 1, 4}]</i> much cleaner than <i>av(3, 1, 4)</i=
>. To me, the message operator[] conveys is "accessing data structure (sub-=
elements)", while operator() should always mean "executing algorithm (calli=
ng a function)". It's unfortunate that we ended up with an overloaded meani=
ng of the latter due to language limitations (cf. C#).&nbsp;Also,&nbsp;it o=
nly comes up when you don't already have an <i>index&lt;N&gt;</i> object (i=
n which case you'd just write <i>av[idx]</i> and this discussion doesn't ma=
tter) but you have integer literals or individual integer variables -- is t=
hat really so bad?</font></span><div>It seems like the argument is migratio=
n from existing code that happens to use operator() because that's all we h=
ad.&nbsp;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 going=
 forward. Is migrating from operator() syntax really a big deal? If yes, wo=
uld it be helpful to add a (redundant) operator() accessor that we immediat=
ely also mark [[deprecated]] to discourage use?<br><br><br></div></div><div=
>My answer:<br>In this case, I think it is pretty bad and could hamstring t=
he interface.&nbsp; I also would prefer a multi-argument [] if building fro=
m=20
scratch, but there is a huge amount of scientific code out there that one w=
ould want to make generic.&nbsp; 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.&nbsp; A [[deprecated]] doesn't hurt (a=
s long as you never actually deprecate it).&nbsp; This just doesn't seem li=
ke a battle worth fighting over aesthetics to me.<br><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>3. <span s=
tyle=3D"font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;font-size:10pt=
"><font color=3D"#000000">*Would be very nice*
reshape() function</font></span></div><div><br></div><div>Can you please he=
lp me understand what part is missing here with the functionality of the&nb=
sp;<i>array_view</i> constructor?</div></div></blockquote><div>You are righ=
t, that is enough.<br>&nbsp;<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div><br></div><div><br></div><div>4. <span style=3D"fo=
nt-family:&quot;Arial&quot;,&quot;sans-serif&quot;;font-size:10pt"><font co=
lor=3D"#000000">*Nice to have sooner
rather than later* Fixed size extents</font></span></div><div><br></div><di=
v>This is interesting, although as you observed -- it can be separated from=
 the "core" proposal into a subsequent one.</div><div>I'm also a bit worrie=
d with polluting the programming model with the concept driven mostly by th=
e optimizer rationale.</div><div>Having said that -- can you give us some s=
pecific motivating examples and data?</div></div></blockquote><div dir=3D"l=
tr"><br>To me, the biggest motivating examples for this are ensuring adapta=
bility and ensuring conformance for tensor/matrix operations.<br><br><b>For=
 optimization: </b>Includes things like SIMD due to fixed extents, managing=
 cache boundaries, etc. that I don't really understand.&nbsp; I also know t=
hat this becomes extremely important for geometry.&nbsp; Many libraries hav=
e handcrafted optimizations for their algorthms with fixed size matrices/ve=
ctor (e.g. <a href=3D"http://eigen.tuxfamily.org/dox/group__TutorialLinearA=
lgebra.html" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.googl=
e.com/url?q\75http%3A%2F%2Feigen.tuxfamily.org%2Fdox%2Fgroup__TutorialLinea=
rAlgebra.html\46sa\75D\46sntz\0751\46usg\75AFQjCNEAa_y5InwQHVgaiXLzRm4_m2E2=
PQ';return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75htt=
p%3A%2F%2Feigen.tuxfamily.org%2Fdox%2Fgroup__TutorialLinearAlgebra.html\46s=
a\75D\46sntz\0751\46usg\75AFQjCNEAa_y5InwQHVgaiXLzRm4_m2E2PQ';return true;"=
>http://eigen.tuxfamily.org/<wbr>dox/group__<wbr>TutorialLinearAlgebra.html=
</a> shows the fixed sizes are all over the place).&nbsp; Think through inv=
erting a matrix&nbsp; if you know it is 2x2 at compiletime and can dispatch=
 to the closed form solution.&nbsp; They will handcraft assembler code to u=
se SSE instructions for things like inner product if they know it fits in t=
he register.&nbsp; I am always suspicious of premature optimization, but 1)=
 these are the sorts of optimizations that library vendors (ie. other peopl=
e) can 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 =
small performance changes can have enormous effects in many applciations.<b=
r><b>For interoperability:</b> The ideal here would be that I can take an a=
rray_view and create adaptor to eigen/ublas/etc.&nbsp; then use their expre=
ssion templates for the sematics.&nbsp; But to generate a static eigen vect=
or/matrix, I need to statically query the bounds of the array_view.<br><b>F=
or conformance: </b>Having static sizes can significantly improve correctne=
ss in generic code at compiletime.&nbsp; For example, making sure that an i=
nner product of two 1D slices have the same length at compile time, etc.<di=
v><br></div><br><div><br></div><div><div>&nbsp;</div><div>On Tuesday, Janua=
ry 28, 2014 11:45:23 AM UTC-8, Jesse Perla wrote:</div></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;bord=
er-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:soli=
d"><div dir=3D"ltr"><div>I think this is exactly the right approach for the=
 standard. &nbsp;Instead of a container, standardize on a view for contiguo=
us 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;=
This may have a chance to be a standard interoperability format, which is c=
rucially needed for those doing numerical work. &nbsp;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.</div><div><div>&nbsp;</div></=
div><div>As use cases for scientific programming, consider the following se=
t of tests for adaptation:</div><div><ol><li>Adaptor written which can "con=
vert" 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, a=
nd matlab MEX extension<div>&nbsp;</div></li><li>Can an efficient adaptor b=
e written for boost numeric_bindings to call a variety of libraries (mostly=
 implementations of LAPACK, MUMPS, UMFPACK, etc. that are often column-majo=
r): <a href=3D"https://svn.boost.org/svn/boost/sandbox/numeric_bindings/boo=
st/numeric/bindings/" target=3D"_blank" onmousedown=3D"this.href=3D'https:/=
/www.google.com/url?q\75https%3A%2F%2Fsvn.boost.org%2Fsvn%2Fboost%2Fsandbox=
%2Fnumeric_bindings%2Fboost%2Fnumeric%2Fbindings%2F\46sa\75D\46sntz\0751\46=
usg\75AFQjCNFhNKBTnvDMHUmGVfcgXpWX0J7Mnw';return true;" onclick=3D"this.hre=
f=3D'https://www.google.com/url?q\75https%3A%2F%2Fsvn.boost.org%2Fsvn%2Fboo=
st%2Fsandbox%2Fnumeric_bindings%2Fboost%2Fnumeric%2Fbindings%2F\46sa\75D\46=
sntz\0751\46usg\75AFQjCNFhNKBTnvDMHUmGVfcgXpWX0J7Mnw';return true;">https:/=
/svn.boost.org/svn/<wbr>boost/sandbox/numeric_<wbr>bindings/boost/numeric/<=
wbr>bindings/</a>. &nbsp;To see if the correct accessors/types are in array=
_view, check out the example adaptor implementations in <a href=3D"https://=
svn.boost.org/svn/boost/sandbox/numeric_bindings/boost/numeric/bindings/boo=
st/multi_array.hpp" target=3D"_blank" onmousedown=3D"this.href=3D'https://w=
ww.google.com/url?q\75https%3A%2F%2Fsvn.boost.org%2Fsvn%2Fboost%2Fsandbox%2=
Fnumeric_bindings%2Fboost%2Fnumeric%2Fbindings%2Fboost%2Fmulti_array.hpp\46=
sa\75D\46sntz\0751\46usg\75AFQjCNGQAR7YmaGZC7_Mvi8rVXkNhKYt4w';return true;=
" onclick=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fsvn.=
boost.org%2Fsvn%2Fboost%2Fsandbox%2Fnumeric_bindings%2Fboost%2Fnumeric%2Fbi=
ndings%2Fboost%2Fmulti_array.hpp\46sa\75D\46sntz\0751\46usg\75AFQjCNGQAR7Ym=
aGZC7_Mvi8rVXkNhKYt4w';return true;">https://svn.boost.org/svn/<wbr>boost/s=
andbox/numeric_<wbr>bindings/boost/numeric/<wbr>bindings/boost/multi_array.=
hpp</a> and <a href=3D"https://svn.boost.org/svn/boost/sandbox/numeric_bind=
ings/boost/numeric/bindings/eigen/matrix.hpp" target=3D"_blank" onmousedown=
=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fsvn.boost.org=
%2Fsvn%2Fboost%2Fsandbox%2Fnumeric_bindings%2Fboost%2Fnumeric%2Fbindings%2F=
eigen%2Fmatrix.hpp\46sa\75D\46sntz\0751\46usg\75AFQjCNGDoUYcES8xClzou_kVsLY=
wCFvzsA';return true;" onclick=3D"this.href=3D'https://www.google.com/url?q=
\75https%3A%2F%2Fsvn.boost.org%2Fsvn%2Fboost%2Fsandbox%2Fnumeric_bindings%2=
Fboost%2Fnumeric%2Fbindings%2Feigen%2Fmatrix.hpp\46sa\75D\46sntz\0751\46usg=
\75AFQjCNGDoUYcES8xClzou_kVsLYwCFvzsA';return true;">https://svn.boost.org/=
svn/<wbr>boost/sandbox/numeric_<wbr>bindings/boost/numeric/<wbr>bindings/ei=
gen/matrix.hpp</a>. &nbsp;One requirement of this would be that the adaptor=
 class should have no storage of its own.<div>&nbsp;</div></li></ol></div><=
div><div>&nbsp;</div></div><div><div>&nbsp;</div></div><div>From the perspe=
ctive of scientific computing, the following are some concerns and addition=
s ordered by necessity:</div><div><ul><li>*Deal killer* Need Static row vs.=
 column major support!!!!</li><ul><li>A large number of scientific librarie=
s are written with column major data. &nbsp;This is especially true when ca=
lling high performance libraries written in fortran, or interfacing with ma=
tlab in MEX. &nbsp;EVERY major container used for numerical analysis has th=
is option.</li><li>boost::multi_array allows a runtime specification for th=
e ordering, but this is overkill. &nbsp;Better is a template parameter whic=
h determines the ordering for every dimension, and which can be queried by =
TMP used in the adaptors. &nbsp;Check out the ordering_type in boost::ublas=
, &nbsp;ColMajor vs. RowMajor in eigen, and the general_storage_order in bo=
ost::multi_array and seimilar ones in GLAS, MTL, etc.</li><li>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.</li><li>I don't see how this could be adde=
d later without breaking a bunch of generic code. &nbsp;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)</li></ul></ul></div><div><ul><li>*Deal ki=
ller* operator()(...) support</li><ul><li>A good portion of generic code is=
 written with operator(), especially using 2D specializations. &nbsp;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. &nbsp;operator() code is much more prevalent here than operator []</l=
i><li>This should be a variadic accessor for a list of extents, and doesn't=
 need to have an index_type version. &nbsp;Having a constexpr specializatio=
n would also be nice and allow optimizations, but is not necessary.</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></div><div><ul><l=
i>*Would be very nice* reshape() function</li><ul><li>It would be nice for =
the user to be able to reshape the array with the same allocated size. &nbs=
p;Not resize! &nbsp;An assert could ensure that the size remains 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, reallocate an e=
ntire copy (e.g. transpose)</li><li>It also comes up a lot in numeric analy=
sis with tensor products and multivariate regressions. &nbsp;(e.g. using th=
e 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_ar=
ray_view: Pass in a static list of extents as a variadic template argument.=
 &nbsp;Would not support a reshape() function as that would be a different =
type. &nbsp;Though a conversion function could be written.</li><li>This ena=
bles a huge number of optimizations and compile time extent checking for er=
rors. &nbsp;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)</li></ul></ul></div><div><ul><li>*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)<div>&nbsp;</div></li></ul></div><div><div>&nbsp;</div></div></div>=
</blockquote></div></div></blockquote></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_472_32734932.1391706542581--

.

------=_Part_4214_31316181.1391709518646
Content-Type: text/plain; charset=UTF-8


On Thu, Feb 6, 2014 at 9:09 AM, Bengt Gustafsson wrote:

> My idea on how to define this in the interface is that the array_view has
> each size as a variadic int template parameter, with 0 (or maybe -1) as a
> placeholder for variable dimensions. 0 would be more beautiful but it goes
> against my other proposal to allow 0 size arrays to some extent. -1 is
> safer and a constant can of course be set to -1:
>

I concur on the need for size-0 dimensions.  Besides it being very useful
for creating generic code (It came up so often when I was writing an
economics library that I ended up modifying boost::ublas to allow it in
Visual Studio), it is also necessary for interoperability with many
libraries.  For example, http://forum.kde.org/viewtopic.php?f=74&t=86595<http://forum.kde.org/viewtopic.php?f=74&t=86595> for
eigen, matlab http://www.mathworks.com/help/matlab/ref/empty.html (and the
corresponding C api that would be wrapped:
http://www.gnu.org/software/octave/doc/interpreter/Working-with-Matrices-and-Arrays-in-Mex_002dFiles.html  ).
 Without this, we couldn't write a matlab MEX serialization library that
uses array_view.   (of course, it is also not possible without Fortran
style ordering of arrays which is necessary in MEX/OCTAVE C/C++ extensions.
 A side note on fortran-style ordering:  many writers of optimization
libraries in C++ are targetting matlab as well, and end up using
fortran-style ordering in their code to ensure it is compatible)

The deal killer with () support may not be so awful in that case, as the
> missing operator() will also cause noise while compiling and the getsize()
> issue needs to be handled anyway, which is probably almost as many
> callsites as operator(). I think it would be a real pity to introduce
> multidim operator[] AND array_view WITHOUT forcing the templating of
> libraries to include changing to []. This is a chance to get it done that
> never will come back!
>

I guess I don't understand why forcing people to use a multi-argument
operator[] is worth all of this trouble?  Is there some use case for the
operator() that we need to reserve it for?  Is this just aesthetics?  If
so, then I think the fact that huge amounts of code use () dominates
aesthetics.  If it supported (), then these libraries could be ported by
just making the function templates generic in the array type without
changing the contents of the functions.

In my mind, operator[] should be about slices and operator() should be used
for random access.  Why?  Because we should conceptually separate the two,
and because operator[] already does a slice on the 1st dimension, with
chained [] taking slices of the slices.  Note that boost::multi_array
already does this: (look at
http://www.boost.org/doc/libs/1_55_0b1/libs/multi_array/doc/reference.html#MultiArray for
example).  Blitz uses operator(), but I think that is because variadic
operator[] wasn't available.  To setup the analogy to matlab to get a slice
of the 2nd dimension you do things like: A(4, :, 2), and to get a sub-array
you go: A(4, 1:3, 2)

With operator[] in C++ this could be things like:
A[4][std::all][2] or A[4, std::all, 2], or A[{4, std::all, 2}]
and
A[4][std::index_range(1,3), 2], etc.

which is basically how boost::multi_array and blitz do it.  Not to say that
this should all be in the first version of this interface, but it should be
thought through as an inevitable extension in the future.  Naturally,
repeated [] or A[1,2,3] to the last dimension still gives random access,
but that is because the slice of a 1D array is a scalar.



> Finally, it seems more and more that array_view is more of a concept than
> an actual class. That is, it will act as a model for other classes in the
> future, which will be designed to work with those templated algorithms.
> This could include for instance dialognal, triangular, banded and sparse
> matrices and views thereof. With this in the back of our heads it becomes
> even more important that the getsize() method is templated on the dimension
> to allow the _concept_ to include, at least, compatible classes to have
> some dimensions of fixed size, some variable.
>

I am not sure I agree.  There may be some sort of multidimensional
equivalent to RandomAccessContainer and RandomAccessIterator here, but a
crucial part of this array view is that it has access to a pointer to the
underlying data and a list of strides.  This doesn't map to the various
types of sparse, banded, etc. data.  (if you want to see the matlab
interface for a sparse multiarray, check
out: http://www.mathworks.com/help/matlab/apiref/mxcreatesparse.html).  So
in some ways, this array_view is implicitly a "dense_array_view", even if
it does not assume contiguous memory (due to the strides).  And
sparse_multi_array iterators may not even support random access.



> I have also been writing a bit in the "2d drawing" thread, and there is
> need for 2D points as well as 2x3 affine transform matrices. If only
> dynamically sized matrices and views are available they will not be used
> for this type of purposes, both for performance reasons and as it is
> awkward to have to check the size of the incoming data every time.
>

Great use case.  Also tensors of rank 2 or 3 come up all over the place in
physics and the stress-strain tensor in elasticity, which have specialized
high performance calculations due to their fixed siize.

--

---
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_4214_31316181.1391709518646
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div><span style=3D"font-family: arial; font-size: sma=
ll;">On Thu, Feb 6, 2014 at 9:09 AM, Bengt Gustafsson</span><span style=3D"=
font-family: arial; font-size: small;">&nbsp;wrote:</span><br style=3D"font=
-family: arial; font-size: small;"><blockquote class=3D"gmail_quote" style=
=3D"font-family: arial; font-size: small; margin: 0px 0px 0px 0.8ex; border=
-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style:=
 solid; padding-left: 1ex;"><div dir=3D"ltr">My idea on how to define this =
in the interface is that the array_view has each size as a variadic int tem=
plate parameter, with 0 (or maybe -1) as a placeholder for variable dimensi=
ons. 0 would be more beautiful but it goes against my other proposal to all=
ow 0 size arrays to some extent. -1 is safer and a constant can of course b=
e set to -1:</div></blockquote><div style=3D"font-family: arial; font-size:=
 small;"><br></div><div style=3D"font-family: arial; font-size: small;">I c=
oncur on the need for size-0 dimensions. &nbsp;Besides it being very useful=
 for creating generic code (It came up so often when I was writing an econo=
mics library that I ended up modifying boost::ublas to allow it in Visual S=
tudio), it is also necessary for interoperability with many libraries. &nbs=
p;For example,<a href=3D"http://forum.kde.org/viewtopic.php?f=3D74&amp;t=3D=
86595" style=3D"color: rgb(17, 85, 204);">&nbsp;http://forum.kde.org/viewto=
pic.php?f=3D74&amp;t=3D86595</a>&nbsp;for eigen, matlab&nbsp;<a href=3D"htt=
p://www.mathworks.com/help/matlab/ref/empty.html" style=3D"color: rgb(17, 8=
5, 204);">http://www.mathworks.com/help/matlab/ref/empty.html</a>&nbsp;(and=
 the corresponding C api that would be wrapped:&nbsp;<a href=3D"http://www.=
gnu.org/software/octave/doc/interpreter/Working-with-Matrices-and-Arrays-in=
-Mex_002dFiles.html" style=3D"color: rgb(17, 85, 204);">http://www.gnu.org/=
software/octave/doc/interpreter/Working-with-Matrices-and-Arrays-in-Mex_002=
dFiles.html</a>&nbsp;&nbsp;). &nbsp;Without this, we couldn't write a matla=
b MEX serialization library that uses array_view. &nbsp; (of course, it is =
also not possible without Fortran style ordering of arrays which is necessa=
ry in MEX/OCTAVE C/C++ extensions. &nbsp;A side note on fortran-style order=
ing: &nbsp;many writers of optimization libraries in C++ are targetting mat=
lab as well, and end up using fortran-style ordering in their code to ensur=
e it is compatible)</div><div style=3D"font-family: arial; font-size: small=
;"><br></div><blockquote class=3D"gmail_quote" style=3D"font-family: arial;=
 font-size: small; margin: 0px 0px 0px 0.8ex; border-left-width: 1px; borde=
r-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1=
ex;"><div dir=3D"ltr">The deal killer with () support may not be so awful i=
n that case, as the missing operator() will also cause noise while compilin=
g and the getsize() issue needs to be handled anyway, which is probably alm=
ost as many callsites as operator(). I think it would be a real pity to int=
roduce multidim operator[] AND array_view WITHOUT forcing the templating of=
 libraries to include changing to []. This is a chance to get it done that =
never will come back!<br></div></blockquote><div style=3D"font-family: aria=
l; font-size: small;"><br></div><div style=3D"font-family: arial; font-size=
: small;">I guess I don't understand why forcing people to use a multi-argu=
ment operator[] is worth all of this trouble? &nbsp;Is there some use case =
for the operator() that we need to reserve it for? &nbsp;Is this just aesth=
etics? &nbsp;If so, then I think the fact that huge amounts of code use () =
dominates aesthetics. &nbsp;If it supported (), then these libraries could =
be ported by just making the function templates generic in the array type w=
ithout changing the contents of the functions.</div><div style=3D"font-fami=
ly: arial; font-size: small;"><br></div><div style=3D"font-family: arial; f=
ont-size: small;">In my mind, operator[] should be about slices and operato=
r() should be used for random access. &nbsp;Why? &nbsp;Because we should co=
nceptually separate the two, and because operator[] already does a slice on=
 the 1st dimension, with chained [] taking slices of the slices. &nbsp;Note=
 that boost::multi_array already does this: (look at&nbsp;<a href=3D"http:/=
/www.boost.org/doc/libs/1_55_0b1/libs/multi_array/doc/reference.html#MultiA=
rray" style=3D"color: rgb(17, 85, 204);">http://www.boost.org/doc/libs/1_55=
_0b1/libs/multi_array/doc/reference.html#MultiArray</a>&nbsp;for example). =
&nbsp;Blitz uses operator(), but I think that is because variadic operator[=
] wasn't available. &nbsp;To setup the analogy to matlab to get a slice of =
the 2nd dimension you do things like: A(4, :, 2), and to get a sub-array yo=
u go: A(4, 1:3, 2)</div><div style=3D"font-family: arial; font-size: small;=
"><br></div><div style=3D"font-family: arial; font-size: small;">With opera=
tor[] in C++ this could be things like:</div><div style=3D"font-family: ari=
al; font-size: small;">A[4][std::all][2] or A[4, std::all, 2], or A[{4, std=
::all, 2}]</div><div style=3D"font-family: arial; font-size: small;">and&nb=
sp;</div><div style=3D"font-family: arial; font-size: small;">A[4][std::ind=
ex_range(1,3), 2], etc.</div><div style=3D"font-family: arial; font-size: s=
mall;"><br></div><div style=3D"font-family: arial; font-size: small;">which=
 is basically how boost::multi_array and blitz do it. &nbsp;Not to say that=
 this should all be in the first version of this interface, but it should b=
e thought through as an inevitable extension in the future. &nbsp;Naturally=
, repeated [] or A[1,2,3] to the last dimension still gives random access, =
but that is because the slice of a 1D array is a scalar.</div><div style=3D=
"font-family: arial; font-size: small;"><br></div><div style=3D"font-family=
: arial; font-size: small;">&nbsp;</div><blockquote class=3D"gmail_quote" s=
tyle=3D"font-family: arial; font-size: small; margin: 0px 0px 0px 0.8ex; bo=
rder-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-st=
yle: solid; padding-left: 1ex;"><div dir=3D"ltr">Finally, it seems more and=
 more that array_view is more of a concept than an actual class. That is, i=
t will act as a model for other classes in the future, which will be design=
ed to work with those templated algorithms. This could include for instance=
 dialognal, triangular, banded and sparse matrices and views thereof. With =
this in the back of our heads it becomes even more important that the getsi=
ze() method is templated on the dimension to allow the _concept_ to include=
, at least, compatible classes to have some dimensions of fixed size, some =
variable.</div></blockquote><div style=3D"font-family: arial; font-size: sm=
all;"><br></div><div style=3D"font-family: arial; font-size: small;">I am n=
ot sure I agree. &nbsp;There may be some sort of multidimensional equivalen=
t to RandomAccessContainer and RandomAccessIterator here, but a crucial par=
t of this array view is that it has access to a pointer to the underlying d=
ata and a list of strides. &nbsp;This doesn't map to the various types of s=
parse, banded, etc. data. &nbsp;(if you want to see the matlab interface fo=
r a sparse multiarray, check out:&nbsp;http://www.mathworks.com/help/matlab=
/apiref/mxcreatesparse.html). &nbsp;So in some ways, this array_view is imp=
licitly a "dense_array_view", even if it does not assume contiguous memory =
(due to the strides). &nbsp;And sparse_multi_array iterators may not even s=
upport random access.</div><div style=3D"font-family: arial; font-size: sma=
ll;"><br></div><div style=3D"font-family: arial; font-size: small;">&nbsp;<=
/div><blockquote class=3D"gmail_quote" style=3D"font-family: arial; font-si=
ze: small; margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-c=
olor: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><di=
v dir=3D"ltr">I have also been writing a bit in the "2d drawing" thread, an=
d there is need for 2D points as well as 2x3 affine transform matrices. If =
only dynamically sized matrices and views are available they will not be us=
ed for this type of purposes, both for performance reasons and as it is awk=
ward to have to check the size of the incoming data every time.<br></div></=
blockquote><div style=3D"font-family: arial; font-size: small;"><br></div><=
div style=3D"font-family: arial; font-size: small;">Great use case. &nbsp;A=
lso tensors of rank 2 or 3 come up all over the place in physics and the st=
ress-strain tensor in elasticity, which have specialized high performance c=
alculations due to their fixed siize.</div></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_4214_31316181.1391709518646--

.

------=_Part_7587_23739815.1391710747437
Content-Type: text/plain; charset=UTF-8


On Thursday, February 6, 2014 9:58:38 AM UTC-8, Jesse Perla wrote:
>
>
> In my mind, operator[] should be about slices and operator() should be
> used for random access.  Why?  Because we should conceptually separate the
> two, and because operator[] already does a slice on the 1st dimension, with
> chained [] taking slices of the slices.  Note that boost::multi_array
> already does this: (look at
> http://www.boost.org/doc/libs/1_55_0b1/libs/multi_array/doc/reference.html#MultiArray for
> example).  Blitz uses operator(), but I think that is because variadic
> operator[] wasn't available.  To setup the analogy to matlab to get a slice
> of the 2nd dimension you do things like: A(4, :, 2), and to get a sub-array
> you go: A(4, 1:3, 2)
>
> Fortran has very natural notation for array access/slices/etc., and
closely matches Matlab/Octave.  For example, see
http://orion.math.iastate.edu/burkardt/papers/fortran_arrays.html

--

---
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_7587_23739815.1391710747437
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Thursday, February 6, 2014 9:58:38 AM UTC-8, Jesse =
Perla wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div style=3D"font-family:arial;font-size:small"><br></div><div style=3D"fon=
t-family:arial;font-size:small">In my mind, operator[] should be about slic=
es and operator() should be used for random access. &nbsp;Why? &nbsp;Becaus=
e we should conceptually separate the two, and because operator[] already d=
oes a slice on the 1st dimension, with chained [] taking slices of the slic=
es. &nbsp;Note that boost::multi_array already does this: (look at&nbsp;<a =
href=3D"http://www.boost.org/doc/libs/1_55_0b1/libs/multi_array/doc/referen=
ce.html#MultiArray" style=3D"color:rgb(17,85,204)" target=3D"_blank" onmous=
edown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.boost.=
org%2Fdoc%2Flibs%2F1_55_0b1%2Flibs%2Fmulti_array%2Fdoc%2Freference.html%23M=
ultiArray\46sa\75D\46sntz\0751\46usg\75AFQjCNFkbVNp4C_k0-iPF79U6jTmHIpfrg';=
return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A=
%2F%2Fwww.boost.org%2Fdoc%2Flibs%2F1_55_0b1%2Flibs%2Fmulti_array%2Fdoc%2Fre=
ference.html%23MultiArray\46sa\75D\46sntz\0751\46usg\75AFQjCNFkbVNp4C_k0-iP=
F79U6jTmHIpfrg';return true;">http://www.boost.org/doc/<wbr>libs/1_55_0b1/l=
ibs/multi_<wbr>array/doc/reference.html#<wbr>MultiArray</a>&nbsp;for exampl=
e). &nbsp;Blitz uses operator(), but I think that is because variadic opera=
tor[] wasn't available. &nbsp;To setup the analogy to matlab to get a slice=
 of the 2nd dimension you do things like: A(4, :, 2), and to get a sub-arra=
y you go: A(4, 1:3, 2)</div><div style=3D"font-family:arial;font-size:small=
"><br></div></div></blockquote><div>Fortran has very natural notation for a=
rray access/slices/etc., and closely matches Matlab/Octave. &nbsp;For examp=
le, see <a href=3D"http://orion.math.iastate.edu/burkardt/papers/fortran_ar=
rays.html">http://orion.math.iastate.edu/burkardt/papers/fortran_arrays.htm=
l</a>&nbsp;</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_7587_23739815.1391710747437--

.

------=_Part_91_30953797.1391727509819
Content-Type: text/plain; charset=UTF-8

Note that when I referred to triangular or sparse matrices I was talking
about array_view as a concept, i.e. that when new algorithms are written
and old code converted to have the "matrix" type as a template they are
callable with anything conforming to the "concept" array_view, such as some
representation of a triangular matrix. This would be some other class
however, such as triangular_matrix or something like that.

My main point was that if the concept is ever to be useful for fixed size
views the getsize() function must be different per dimension (So that some
can be constexpr). As we don't know the number of dimensions the logical
thing to do is to
use a template<int> getsize() as the main api to get sizes. An auxiliary
getsize(dim) can be built on top.

Den torsdagen den 6:e februari 2014 kl. 19:19:07 UTC+1 skrev Jesse Perla:
>
>
> On Thursday, February 6, 2014 9:58:38 AM UTC-8, Jesse Perla wrote:
>>
>>
>> In my mind, operator[] should be about slices and operator() should be
>> used for random access.  Why?  Because we should conceptually separate the
>> two, and because operator[] already does a slice on the 1st dimension, with
>> chained [] taking slices of the slices.  Note that boost::multi_array
>> already does this: (look at
>> http://www.boost.org/doc/libs/1_55_0b1/libs/multi_array/doc/reference.html#MultiArray for
>> example).  Blitz uses operator(), but I think that is because variadic
>> operator[] wasn't available.  To setup the analogy to matlab to get a slice
>> of the 2nd dimension you do things like: A(4, :, 2), and to get a sub-array
>> you go: A(4, 1:3, 2)
>>
>> Fortran has very natural notation for array access/slices/etc., and
> closely matches Matlab/Octave.  For example, see
> http://orion.math.iastate.edu/burkardt/papers/fortran_arrays.html
>

--

---
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_91_30953797.1391727509819
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Note that when I referred to triangular or sparse matrices=
 I was talking about array_view as a concept, i.e. that when new algorithms=
 are written and old code converted to have the "matrix" type as a template=
 they are callable with anything conforming to the "concept" array_view, su=
ch as some representation of a triangular matrix. This would be some other =
class however, such as triangular_matrix or something like that.<div><br></=
div><div>My main point was that if the concept is ever to be useful for fix=
ed size views the getsize() function must be different per dimension (So th=
at some can be constexpr). As we don't know the number of dimensions the lo=
gical thing to do is to</div><div>use a template&lt;int&gt; getsize() as th=
e main api to get sizes. An auxiliary getsize(dim) can be built on top.<br>=
<br>Den torsdagen den 6:e februari 2014 kl. 19:19:07 UTC+1 skrev Jesse Perl=
a:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br>On Thur=
sday, February 6, 2014 9:58:38 AM UTC-8, Jesse Perla wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div style=3D"font-family:arial;fo=
nt-size:small"><br></div><div style=3D"font-family:arial;font-size:small">I=
n my mind, operator[] should be about slices and operator() should be used =
for random access. &nbsp;Why? &nbsp;Because we should conceptually separate=
 the two, and because operator[] already does a slice on the 1st dimension,=
 with chained [] taking slices of the slices. &nbsp;Note that boost::multi_=
array already does this: (look at&nbsp;<a href=3D"http://www.boost.org/doc/=
libs/1_55_0b1/libs/multi_array/doc/reference.html#MultiArray" style=3D"colo=
r:rgb(17,85,204)" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.=
google.com/url?q\75http%3A%2F%2Fwww.boost.org%2Fdoc%2Flibs%2F1_55_0b1%2Flib=
s%2Fmulti_array%2Fdoc%2Freference.html%23MultiArray\46sa\75D\46sntz\0751\46=
usg\75AFQjCNFkbVNp4C_k0-iPF79U6jTmHIpfrg';return true;" onclick=3D"this.hre=
f=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.boost.org%2Fdoc%2Flibs%=
2F1_55_0b1%2Flibs%2Fmulti_array%2Fdoc%2Freference.html%23MultiArray\46sa\75=
D\46sntz\0751\46usg\75AFQjCNFkbVNp4C_k0-iPF79U6jTmHIpfrg';return true;">htt=
p://www.boost.org/doc/<wbr>libs/1_55_0b1/libs/multi_<wbr>array/doc/referenc=
e.html#<wbr>MultiArray</a>&nbsp;for example). &nbsp;Blitz uses operator(), =
but I think that is because variadic operator[] wasn't available. &nbsp;To =
setup the analogy to matlab to get a slice of the 2nd dimension you do thin=
gs like: A(4, :, 2), and to get a sub-array you go: A(4, 1:3, 2)</div><div =
style=3D"font-family:arial;font-size:small"><br></div></div></blockquote><d=
iv>Fortran has very natural notation for array access/slices/etc., and clos=
ely matches Matlab/Octave. &nbsp;For example, see <a href=3D"http://orion.m=
ath.iastate.edu/burkardt/papers/fortran_arrays.html" target=3D"_blank" onmo=
usedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Forion.ma=
th.iastate.edu%2Fburkardt%2Fpapers%2Ffortran_arrays.html\46sa\75D\46sntz\07=
51\46usg\75AFQjCNGBeXq5XzkQ-0Oe_meGmAXaM2_CWw';return true;" onclick=3D"thi=
s.href=3D'http://www.google.com/url?q\75http%3A%2F%2Forion.math.iastate.edu=
%2Fburkardt%2Fpapers%2Ffortran_arrays.html\46sa\75D\46sntz\0751\46usg\75AFQ=
jCNGBeXq5XzkQ-0Oe_meGmAXaM2_CWw';return true;">http://orion.math.iastate.ed=
u/<wbr>burkardt/papers/fortran_<wbr>arrays.html</a>&nbsp;</div></div></bloc=
kquote></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_91_30953797.1391727509819--

.

------=_Part_28_29878208.1391793720333
Content-Type: text/plain; charset=UTF-8


On Thursday, February 6, 2014 2:58:29 PM UTC-8, Bengt Gustafsson wrote:
>
> Note that when I referred to triangular or sparse matrices I was talking
> about array_view as a concept, i.e. that when new algorithms are written
> and old code converted to have the "matrix" type as a template they are
> callable with anything conforming to the "concept" array_view, such as some
> representation of a triangular matrix. This would be some other class
> however, such as triangular_matrix or something like that.
>
> Yup, I think we are thinking the same thing. I guess what I was thinking
was that the array_view concept, may not be able to apply to both sparse
and dense, or the common elements of these might be small (getsize
certainly is one of them).  This is a tough design decision that needs to
figure out what operations sparse multi_array iterators might have.


> My main point was that if the concept is ever to be useful for fixed size
> views the getsize() function must be different per dimension (So that some
> can be constexpr). As we don't know the number of dimensions the logical
> thing to do is to
> use a template<int> getsize() as the main api to get sizes. An auxiliary
> getsize(dim) can be built on top.
>

One other comment on the fixed size (and potentially dynamic sized) that I
just thought of.  I am not sure how prevalent these are in the dynamic
types (though Eigen seems to have lots of it:
http://eigen.tuxfamily.org/dox/group__enums.html#gga0c5bde183ecefe103f70b49ad9740bcda02a97bb4792f98916a1156a521fa9813)
, but they are all over the fixed size types

These things often use alignment tricks to get maximum efficiency
(especially with SIMD).  See the following on eigen:
http://www.mrpt.org/tutorials/programming/maths-and-geometry/matrices_vectors_arrays_and_linear_algebra_mrpt_and_eigen_classes/ and
http://eigen.tuxfamily.org/dox-devel/group__DenseMatrixManipulation__Alignement.html
 as an example.  Also see
http://viennacl.sourceforge.net/doc/classviennacl_1_1matrix.html    This is
also used all over GPU programming, such as
http://stackoverflow.com/questions/13008096/aligning-gpu-memory-accesses-of-an-image-convolution-opencl-cuda-kernel
  While this sort of interface may not directly work on GPUs (yet)   It is
much more efficient to copy memory back and forth if you don't need to
transform it every time to change the alignment.

Since the primary reason to use fixed size arrays is efficiency and
optimization, interfacing with these sorts of views is first order.  I
suspect that almost all small matrix/vector libraries use these tricks.
 The alignment of a fixed_array_view would have to be a template parameter,
as it would change iterators and element acccess statically.  This is way
out of my pay grade to say much more on.  My guess is that the SIMD people
would know a lot more:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3759.html  and
http://isocpp.org/files/papers/n3571.pdf , Even if these proposals didn't
go forward, thinking through this sort of integration is important before
solidifying any fixed size interface.


--

---
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_28_29878208.1391793720333
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Thursday, February 6, 2014 2:58:29 PM UTC-8, Bengt =
Gustafsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">Note that when I referred to triangular or sparse matrices I was talkin=
g about array_view as a concept, i.e. that when new algorithms are written =
and old code converted to have the "matrix" type as a template they are cal=
lable with anything conforming to the "concept" array_view, such as some re=
presentation of a triangular matrix. This would be some other class however=
, such as triangular_matrix or something like that.<div><br></div></div></b=
lockquote><div>Yup, I think we are thinking the same thing. I guess what I =
was thinking was that the array_view concept, may not be able to apply to b=
oth sparse and dense, or the common elements of these might be small (getsi=
ze certainly is one of them). &nbsp;This is a tough design decision that ne=
eds to figure out what operations sparse multi_array iterators might have.<=
/div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div></div><div>My main point was that if the concept is ever to b=
e useful for fixed size views the getsize() function must be different per =
dimension (So that some can be constexpr). As we don't know the number of d=
imensions the logical thing to do is to</div><div>use a template&lt;int&gt;=
 getsize() as the main api to get sizes. An auxiliary getsize(dim) can be b=
uilt on top.<br></div></div></blockquote><div><br></div><div>One other comm=
ent on the fixed size (and potentially dynamic sized) that I just thought o=
f. &nbsp;I am not sure how prevalent these are in the dynamic types (though=
 Eigen seems to have lots of it: <a href=3D"http://eigen.tuxfamily.org/dox/=
group__enums.html#gga0c5bde183ecefe103f70b49ad9740bcda02a97bb4792f98916a115=
6a521fa9813">http://eigen.tuxfamily.org/dox/group__enums.html#gga0c5bde183e=
cefe103f70b49ad9740bcda02a97bb4792f98916a1156a521fa9813</a>) , but they are=
 all over the fixed size types</div><div><br></div><div>These things often =
use alignment tricks to get maximum efficiency (especially with SIMD). &nbs=
p;See the following on eigen:&nbsp;<a href=3D"http://www.mrpt.org/tutorials=
/programming/maths-and-geometry/matrices_vectors_arrays_and_linear_algebra_=
mrpt_and_eigen_classes/">http://www.mrpt.org/tutorials/programming/maths-an=
d-geometry/matrices_vectors_arrays_and_linear_algebra_mrpt_and_eigen_classe=
s/</a> &nbsp;and&nbsp;<a href=3D"http://eigen.tuxfamily.org/dox-devel/group=
__DenseMatrixManipulation__Alignement.html">http://eigen.tuxfamily.org/dox-=
devel/group__DenseMatrixManipulation__Alignement.html</a>&nbsp; &nbsp;as an=
 example. &nbsp;Also see&nbsp;<a href=3D"http://viennacl.sourceforge.net/do=
c/classviennacl_1_1matrix.html">http://viennacl.sourceforge.net/doc/classvi=
ennacl_1_1matrix.html</a>&nbsp; &nbsp; This is also used all over GPU progr=
amming, such as&nbsp;<a href=3D"http://stackoverflow.com/questions/13008096=
/aligning-gpu-memory-accesses-of-an-image-convolution-opencl-cuda-kernel">h=
ttp://stackoverflow.com/questions/13008096/aligning-gpu-memory-accesses-of-=
an-image-convolution-opencl-cuda-kernel</a>&nbsp; &nbsp; While this sort of=
 interface may not directly work on GPUs (yet) &nbsp; It is much more effic=
ient to copy memory back and forth if you don't need to transform it every =
time to change the alignment.</div><div><br></div><div>Since the primary re=
ason to use fixed size arrays is efficiency and optimization, interfacing w=
ith these sorts of views is first order. &nbsp;I suspect that almost all sm=
all matrix/vector libraries use these tricks. &nbsp;The alignment of a fixe=
d_array_view would have to be a template parameter, as it would change iter=
ators and element acccess statically. &nbsp;This is way out of my pay grade=
 to say much more on. &nbsp;My guess is that the SIMD people would know a l=
ot more:&nbsp;<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers=
/2013/n3759.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n=
3759.html</a> &nbsp;and&nbsp;<a href=3D"http://isocpp.org/files/papers/n357=
1.pdf">http://isocpp.org/files/papers/n3571.pdf</a> , Even if these proposa=
ls didn't go forward, thinking through this sort of integration is importan=
t before solidifying any fixed size interface.</div><div>&nbsp;</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_28_29878208.1391793720333--

.

------=_Part_911_4436453.1391800082082
Content-Type: text/plain; charset=UTF-8

Well, sparse matrices are another kind althogether. Of course they can get
an array_view compatible API but that would be very inefficient in real
algorithms. I don't know much about this except that they are usually
designed so that serial access to elements from upper left is most
efficient (they store basically the "next non-zero index and value" in two
parallel arrays. Thus to make efficient use of them, as you wrote, requires
alot of inside knowledge not in the regular array_view api.

This seems to be akin to iterator categories. I don't think we have to
worry about this, what can easily be added later is a traits system so that
you can detect whether something passed in as a array_view concept
"compatible" object is actually a sparse matrix and some algorithms can
detect this (at compile time of course) and dispatch to a smarter
implementation.

The other thing is the "mode" according to your link, which tells the
called function that the matrix is tirangular or whatever, _without_
changing its class, that is, how elements are stored. It is just a
guarantee from the caller. Of course you could change the storage mode, but
then we are in the category above that can be handled by traits. The
question here is whether we need runtime dispatch. I don't think so. This
means that it would be easy to device a triangular_array_view by just doing
a "nop" subclassing. If many different modes are to be handled a "nop"
template parameter can be introduced to trigger the traits class. I don't
see that this affects this proposal or that this warrants an extra Mode
template parameter on the "classic" array_view.

This system would be orthogonal to whether the arrayts are fixed or
dynamically sized.

Den fredagen den 7:e februari 2014 kl. 18:22:00 UTC+1 skrev Jesse Perla:
>
>
> On Thursday, February 6, 2014 2:58:29 PM UTC-8, Bengt Gustafsson wrote:
>>
>> Note that when I referred to triangular or sparse matrices I was talking
>> about array_view as a concept, i.e. that when new algorithms are written
>> and old code converted to have the "matrix" type as a template they are
>> callable with anything conforming to the "concept" array_view, such as some
>> representation of a triangular matrix. This would be some other class
>> however, such as triangular_matrix or something like that.
>>
>> Yup, I think we are thinking the same thing. I guess what I was thinking
> was that the array_view concept, may not be able to apply to both sparse
> and dense, or the common elements of these might be small (getsize
> certainly is one of them).  This is a tough design decision that needs to
> figure out what operations sparse multi_array iterators might have.
>
>
>> My main point was that if the concept is ever to be useful for fixed size
>> views the getsize() function must be different per dimension (So that some
>> can be constexpr). As we don't know the number of dimensions the logical
>> thing to do is to
>> use a template<int> getsize() as the main api to get sizes. An auxiliary
>> getsize(dim) can be built on top.
>>
>
> One other comment on the fixed size (and potentially dynamic sized) that I
> just thought of.  I am not sure how prevalent these are in the dynamic
> types (though Eigen seems to have lots of it:
> http://eigen.tuxfamily.org/dox/group__enums.html#gga0c5bde183ecefe103f70b49ad9740bcda02a97bb4792f98916a1156a521fa9813)
> , but they are all over the fixed size types
>
> These things often use alignment tricks to get maximum efficiency
> (especially with SIMD).  See the following on eigen:
> http://www.mrpt.org/tutorials/programming/maths-and-geometry/matrices_vectors_arrays_and_linear_algebra_mrpt_and_eigen_classes/ and
> http://eigen.tuxfamily.org/dox-devel/group__DenseMatrixManipulation__Alignement.html
>  as an example.  Also see
> http://viennacl.sourceforge.net/doc/classviennacl_1_1matrix.html    This
> is also used all over GPU programming, such as
> http://stackoverflow.com/questions/13008096/aligning-gpu-memory-accesses-of-an-image-convolution-opencl-cuda-kernel
>   While this sort of interface may not directly work on GPUs (yet)   It is
> much more efficient to copy memory back and forth if you don't need to
> transform it every time to change the alignment.
>
> Since the primary reason to use fixed size arrays is efficiency and
> optimization, interfacing with these sorts of views is first order.  I
> suspect that almost all small matrix/vector libraries use these tricks.
>  The alignment of a fixed_array_view would have to be a template parameter,
> as it would change iterators and element acccess statically.  This is way
> out of my pay grade to say much more on.  My guess is that the SIMD people
> would know a lot more:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3759.html  and
> http://isocpp.org/files/papers/n3571.pdf , Even if these proposals didn't
> go forward, thinking through this sort of integration is important before
> solidifying any fixed size interface.
>
>
>

--

---
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_911_4436453.1391800082082
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Well, sparse matrices are another kind althogether. Of cou=
rse they can get an array_view compatible API but that would be very ineffi=
cient in real algorithms. I don't know much about this except that they are=
 usually designed so that serial access to elements from upper left is most=
 efficient (they store basically the "next non-zero index and value" in two=
 parallel arrays. Thus to make efficient use of them, as you wrote, require=
s alot of inside knowledge not in the regular array_view api.<div><br></div=
><div>This seems to be akin to iterator categories. I don't think we have t=
o worry about this, what can easily be added later is a traits system so th=
at you can detect whether something passed in as a array_view concept "comp=
atible" object is actually a sparse matrix and some algorithms can detect t=
his (at compile time of course) and dispatch to a smarter implementation.</=
div><div><br></div><div>The other thing is the "mode" according to your lin=
k, which tells the called function that the matrix is tirangular or whateve=
r, _without_ changing its class, that is, how elements are stored. It is ju=
st a guarantee from the caller. Of course you could change the storage mode=
, but then we are in the category above that can be handled by traits. The =
question here is whether we need runtime dispatch. I don't think so. This m=
eans that it would be easy to device a triangular_array_view by just doing =
a "nop" subclassing. If many different modes are to be handled a "nop" temp=
late parameter can be introduced to trigger the traits class. I don't see t=
hat this affects this proposal or that this warrants an extra Mode template=
 parameter on the "classic" array_view.</div><div><br></div><div>This syste=
m would be orthogonal to whether the arrayts are fixed or dynamically sized=
..&nbsp;<br><br>Den fredagen den 7:e februari 2014 kl. 18:22:00 UTC+1 skrev =
Jesse Perla:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
br>On Thursday, February 6, 2014 2:58:29 PM UTC-8, Bengt Gustafsson wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Note that when I re=
ferred to triangular or sparse matrices I was talking about array_view as a=
 concept, i.e. that when new algorithms are written and old code converted =
to have the "matrix" type as a template they are callable with anything con=
forming to the "concept" array_view, such as some representation of a trian=
gular matrix. This would be some other class however, such as triangular_ma=
trix or something like that.<div><br></div></div></blockquote><div>Yup, I t=
hink we are thinking the same thing. I guess what I was thinking was that t=
he array_view concept, may not be able to apply to both sparse and dense, o=
r the common elements of these might be small (getsize certainly is one of =
them). &nbsp;This is a tough design decision that needs to figure out what =
operations sparse multi_array iterators might have.</div><div>&nbsp;</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>My =
main point was that if the concept is ever to be useful for fixed size view=
s the getsize() function must be different per dimension (So that some can =
be constexpr). As we don't know the number of dimensions the logical thing =
to do is to</div><div>use a template&lt;int&gt; getsize() as the main api t=
o get sizes. An auxiliary getsize(dim) can be built on top.<br></div></div>=
</blockquote><div><br></div><div>One other comment on the fixed size (and p=
otentially dynamic sized) that I just thought of. &nbsp;I am not sure how p=
revalent these are in the dynamic types (though Eigen seems to have lots of=
 it: <a href=3D"http://eigen.tuxfamily.org/dox/group__enums.html#gga0c5bde1=
83ecefe103f70b49ad9740bcda02a97bb4792f98916a1156a521fa9813" target=3D"_blan=
k" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fe=
igen.tuxfamily.org%2Fdox%2Fgroup__enums.html%23gga0c5bde183ecefe103f70b49ad=
9740bcda02a97bb4792f98916a1156a521fa9813\46sa\75D\46sntz\0751\46usg\75AFQjC=
NFZpaDB3NI-EgRR1tIgAyI_8ZAJoA';return true;" onclick=3D"this.href=3D'http:/=
/www.google.com/url?q\75http%3A%2F%2Feigen.tuxfamily.org%2Fdox%2Fgroup__enu=
ms.html%23gga0c5bde183ecefe103f70b49ad9740bcda02a97bb4792f98916a1156a521fa9=
813\46sa\75D\46sntz\0751\46usg\75AFQjCNFZpaDB3NI-EgRR1tIgAyI_8ZAJoA';return=
 true;">http://eigen.tuxfamily.org/<wbr>dox/group__enums.html#<wbr>gga0c5bd=
e183ecefe103f70b49ad97<wbr>40bcda02a97bb4792f98916a1156a5<wbr>21fa9813</a>)=
 , but they are all over the fixed size types</div><div><br></div><div>Thes=
e things often use alignment tricks to get maximum efficiency (especially w=
ith SIMD). &nbsp;See the following on eigen:&nbsp;<a href=3D"http://www.mrp=
t.org/tutorials/programming/maths-and-geometry/matrices_vectors_arrays_and_=
linear_algebra_mrpt_and_eigen_classes/" target=3D"_blank" onmousedown=3D"th=
is.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.mrpt.org%2Ftutori=
als%2Fprogramming%2Fmaths-and-geometry%2Fmatrices_vectors_arrays_and_linear=
_algebra_mrpt_and_eigen_classes%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNERCHc=
OzzsUq44zMXb3qzCkv7JUMQ';return true;" onclick=3D"this.href=3D'http://www.g=
oogle.com/url?q\75http%3A%2F%2Fwww.mrpt.org%2Ftutorials%2Fprogramming%2Fmat=
hs-and-geometry%2Fmatrices_vectors_arrays_and_linear_algebra_mrpt_and_eigen=
_classes%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNERCHcOzzsUq44zMXb3qzCkv7JUMQ=
';return true;">http://www.mrpt.org/<wbr>tutorials/programming/maths-<wbr>a=
nd-geometry/matrices_vectors_<wbr>arrays_and_linear_algebra_<wbr>mrpt_and_e=
igen_classes/</a> &nbsp;and&nbsp;<a href=3D"http://eigen.tuxfamily.org/dox-=
devel/group__DenseMatrixManipulation__Alignement.html" target=3D"_blank" on=
mousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Feigen.=
tuxfamily.org%2Fdox-devel%2Fgroup__DenseMatrixManipulation__Alignement.html=
\46sa\75D\46sntz\0751\46usg\75AFQjCNGxFgFoymgIsFG8RJO-v1k7Kg3xZw';return tr=
ue;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Feig=
en.tuxfamily.org%2Fdox-devel%2Fgroup__DenseMatrixManipulation__Alignement.h=
tml\46sa\75D\46sntz\0751\46usg\75AFQjCNGxFgFoymgIsFG8RJO-v1k7Kg3xZw';return=
 true;">http://eigen.tuxfamily.<wbr>org/dox-devel/group__<wbr>DenseMatrixMa=
nipulation__<wbr>Alignement.html</a>&nbsp; &nbsp;as an example. &nbsp;Also =
see&nbsp;<a href=3D"http://viennacl.sourceforge.net/doc/classviennacl_1_1ma=
trix.html" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\75http%3A%2F%2Fviennacl.sourceforge.net%2Fdoc%2Fclassviennacl_1_1=
matrix.html\46sa\75D\46sntz\0751\46usg\75AFQjCNFzQ-0gFIDT7FtrZsdbdgtcMgeAQg=
';return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%=
3A%2F%2Fviennacl.sourceforge.net%2Fdoc%2Fclassviennacl_1_1matrix.html\46sa\=
75D\46sntz\0751\46usg\75AFQjCNFzQ-0gFIDT7FtrZsdbdgtcMgeAQg';return true;">h=
ttp://viennacl.<wbr>sourceforge.net/doc/<wbr>classviennacl_1_1matrix.html</=
a>&nbsp; &nbsp; This is also used all over GPU programming, such as&nbsp;<a=
 href=3D"http://stackoverflow.com/questions/13008096/aligning-gpu-memory-ac=
cesses-of-an-image-convolution-opencl-cuda-kernel" target=3D"_blank" onmous=
edown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fstackoverf=
low.com%2Fquestions%2F13008096%2Faligning-gpu-memory-accesses-of-an-image-c=
onvolution-opencl-cuda-kernel\46sa\75D\46sntz\0751\46usg\75AFQjCNEBMqLwjVHG=
cwlAuW-kR3JshWBvhQ';return true;" onclick=3D"this.href=3D'http://www.google=
..com/url?q\75http%3A%2F%2Fstackoverflow.com%2Fquestions%2F13008096%2Faligni=
ng-gpu-memory-accesses-of-an-image-convolution-opencl-cuda-kernel\46sa\75D\=
46sntz\0751\46usg\75AFQjCNEBMqLwjVHGcwlAuW-kR3JshWBvhQ';return true;">http:=
//stackoverflow.com/<wbr>questions/13008096/aligning-<wbr>gpu-memory-access=
es-of-an-<wbr>image-convolution-opencl-cuda-<wbr>kernel</a>&nbsp; &nbsp; Wh=
ile this sort of interface may not directly work on GPUs (yet) &nbsp; It is=
 much more efficient to copy memory back and forth if you don't need to tra=
nsform it every time to change the alignment.</div><div><br></div><div>Sinc=
e the primary reason to use fixed size arrays is efficiency and optimizatio=
n, interfacing with these sorts of views is first order. &nbsp;I suspect th=
at almost all small matrix/vector libraries use these tricks. &nbsp;The ali=
gnment of a fixed_array_view would have to be a template parameter, as it w=
ould change iterators and element acccess statically. &nbsp;This is way out=
 of my pay grade to say much more on. &nbsp;My guess is that the SIMD peopl=
e would know a lot more:&nbsp;<a href=3D"http://www.open-std.org/jtc1/sc22/=
wg21/docs/papers/2013/n3759.html" target=3D"_blank" onmousedown=3D"this.hre=
f=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fs=
c22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3759.html\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNEqRDTG7ixBKCwgU37cQLMQP2i7Eg';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2=
Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3759.html\46sa\75D\46sntz\0751\46usg\75AFQj=
CNEqRDTG7ixBKCwgU37cQLMQP2i7Eg';return true;">http://www.open-std.org/<wbr>=
jtc1/sc22/wg21/docs/papers/<wbr>2013/n3759.html</a> &nbsp;and&nbsp;<a href=
=3D"http://isocpp.org/files/papers/n3571.pdf" target=3D"_blank" onmousedown=
=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fisocpp.org%2Ffi=
les%2Fpapers%2Fn3571.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNEFFddMJqPqbn_AZ=
YXFdDaXo_j60g';return true;" onclick=3D"this.href=3D'http://www.google.com/=
url?q\75http%3A%2F%2Fisocpp.org%2Ffiles%2Fpapers%2Fn3571.pdf\46sa\75D\46snt=
z\0751\46usg\75AFQjCNEFFddMJqPqbn_AZYXFdDaXo_j60g';return true;">http://iso=
cpp.org/files/<wbr>papers/n3571.pdf</a> , Even if these proposals didn't go=
 forward, thinking through this sort of integration is important before sol=
idifying any fixed size interface.</div><div>&nbsp;</div><div><br></div></d=
iv></blockquote></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_911_4436453.1391800082082--

.

------=_Part_2743_33301926.1391988658704
Content-Type: text/plain; charset=UTF-8

It suddenly struck me that we are basically trying to create
multi-dimensional ranges. I have seen range-related suggestions to reverse
ranges, take subranges, etc. which are essentially the one dimensional
version of array slices, mirroring, etc. Of course transposition is not
evident in one dimensional data for obvious reasons.

As far as I know the range group is working with an idea of using the
"pipe" concept of unix shell, so that you start with your source data and
then apply modifiers, like so.

for (auto x : my_vector | slice(0, 10) | reversed)
   -- process 10 first elements backwards --;

At the same time string_view is being designed, which is a kind of a range
with extra APIs to mimic the API of std::string. Here the naming is the
interesting part:

A string_view is basically a view to a substring.

An array_view is a way of specifying the dimensions and bounds of some data
that is an adaptation of an one-dimensional dataset, such as a C array or a
vector. It can also be used to adapt non standard matrix types such as from
Blitz++ or whatever library you have, given you can get the data pointer to
the first element.

This means that for strings a view is a "slice" while for arrays it is an
adaptor of data type. I don't feel really comfortable with those different
things having the same suffix on their names, but maybe if we make sure
that the functionality is similar enough.

I would like us to try to unite the terminology for one- and
multidimensional data, and I think that it would also be wise to go through
the range() group writings to see if their modifiers can be extended to
many dimensions without compromising their efficiency or ease of use for
the one dimensional case. I have a hunch they can... at least the relevant
ones. Then some more are needed of course, such as transpose.

Unfortunately I don't have the google group for SG9 - Ranges, is there one
yet?



Den fredagen den 7:e februari 2014 kl. 20:08:02 UTC+1 skrev Bengt
Gustafsson:
>
> Well, sparse matrices are another kind althogether. Of course they can get
> an array_view compatible API but that would be very inefficient in real
> algorithms. I don't know much about this except that they are usually
> designed so that serial access to elements from upper left is most
> efficient (they store basically the "next non-zero index and value" in two
> parallel arrays. Thus to make efficient use of them, as you wrote, requires
> alot of inside knowledge not in the regular array_view api.
>
> This seems to be akin to iterator categories. I don't think we have to
> worry about this, what can easily be added later is a traits system so that
> you can detect whether something passed in as a array_view concept
> "compatible" object is actually a sparse matrix and some algorithms can
> detect this (at compile time of course) and dispatch to a smarter
> implementation.
>
> The other thing is the "mode" according to your link, which tells the
> called function that the matrix is tirangular or whatever, _without_
> changing its class, that is, how elements are stored. It is just a
> guarantee from the caller. Of course you could change the storage mode, but
> then we are in the category above that can be handled by traits. The
> question here is whether we need runtime dispatch. I don't think so. This
> means that it would be easy to device a triangular_array_view by just doing
> a "nop" subclassing. If many different modes are to be handled a "nop"
> template parameter can be introduced to trigger the traits class. I don't
> see that this affects this proposal or that this warrants an extra Mode
> template parameter on the "classic" array_view.
>
> This system would be orthogonal to whether the arrayts are fixed or
> dynamically sized.
>
> Den fredagen den 7:e februari 2014 kl. 18:22:00 UTC+1 skrev Jesse Perla:
>>
>>
>> On Thursday, February 6, 2014 2:58:29 PM UTC-8, Bengt Gustafsson wrote:
>>>
>>> Note that when I referred to triangular or sparse matrices I was talking
>>> about array_view as a concept, i.e. that when new algorithms are written
>>> and old code converted to have the "matrix" type as a template they are
>>> callable with anything conforming to the "concept" array_view, such as some
>>> representation of a triangular matrix. This would be some other class
>>> however, such as triangular_matrix or something like that.
>>>
>>> Yup, I think we are thinking the same thing. I guess what I was thinking
>> was that the array_view concept, may not be able to apply to both sparse
>> and dense, or the common elements of these might be small (getsize
>> certainly is one of them).  This is a tough design decision that needs to
>> figure out what operations sparse multi_array iterators might have.
>>
>>
>>> My main point was that if the concept is ever to be useful for fixed
>>> size views the getsize() function must be different per dimension (So that
>>> some can be constexpr). As we don't know the number of dimensions the
>>> logical thing to do is to
>>> use a template<int> getsize() as the main api to get sizes. An auxiliary
>>> getsize(dim) can be built on top.
>>>
>>
>> One other comment on the fixed size (and potentially dynamic sized) that
>> I just thought of.  I am not sure how prevalent these are in the dynamic
>> types (though Eigen seems to have lots of it:
>> http://eigen.tuxfamily.org/dox/group__enums.html#gga0c5bde183ecefe103f70b49ad9740bcda02a97bb4792f98916a1156a521fa9813)
>> , but they are all over the fixed size types
>>
>> These things often use alignment tricks to get maximum efficiency
>> (especially with SIMD).  See the following on eigen:
>> http://www.mrpt.org/tutorials/programming/maths-and-geometry/matrices_vectors_arrays_and_linear_algebra_mrpt_and_eigen_classes/ and
>> http://eigen.tuxfamily.org/dox-devel/group__DenseMatrixManipulation__Alignement.html
>>  as an example.  Also see
>> http://viennacl.sourceforge.net/doc/classviennacl_1_1matrix.html    This
>> is also used all over GPU programming, such as
>> http://stackoverflow.com/questions/13008096/aligning-gpu-memory-accesses-of-an-image-convolution-opencl-cuda-kernel
>>   While this sort of interface may not directly work on GPUs (yet)   It is
>> much more efficient to copy memory back and forth if you don't need to
>> transform it every time to change the alignment.
>>
>> Since the primary reason to use fixed size arrays is efficiency and
>> optimization, interfacing with these sorts of views is first order.  I
>> suspect that almost all small matrix/vector libraries use these tricks.
>>  The alignment of a fixed_array_view would have to be a template parameter,
>> as it would change iterators and element acccess statically.  This is way
>> out of my pay grade to say much more on.  My guess is that the SIMD people
>> would know a lot more:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3759.html  and
>> http://isocpp.org/files/papers/n3571.pdf , Even if these proposals
>> didn't go forward, thinking through this sort of integration is important
>> before solidifying any fixed size interface.
>>
>>
>>

--

---
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_2743_33301926.1391988658704
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It suddenly struck me that we are basically trying to crea=
te multi-dimensional ranges. I have seen range-related suggestions to rever=
se ranges, take subranges, etc. which are essentially the one dimensional v=
ersion of array slices, mirroring, etc. Of course transposition is not evid=
ent in one dimensional data for obvious reasons.<div><br></div><div>As far =
as I know the range group is working with an idea of using the "pipe" conce=
pt of unix shell, so that you start with your source data and then apply mo=
difiers, like so.</div><div><br></div><div>for (auto x : my_vector | slice(=
0, 10) | reversed)</div><div>&nbsp; &nbsp;-- process 10 first elements back=
wards --;</div><div><br></div><div>At the same time string_view is being de=
signed, which is a kind of a range with extra APIs to mimic the API of std:=
:string. Here the naming is the interesting part:</div><div><br></div><div>=
A string_view is basically a view to a substring.</div><div><br></div><div>=
An array_view is a way of specifying the dimensions and bounds of some data=
 that is an adaptation of an one-dimensional dataset, such as a C array or =
a vector. It can also be used to adapt non standard matrix types such as fr=
om Blitz++ or whatever library you have, given you can get the data pointer=
 to the first element.</div><div><br></div><div><span style=3D"font-size: 1=
3px;">This means that for strings a view is a "slice" while for arrays it i=
s an adaptor of data type. I don't feel really comfortable with those diffe=
rent things having the same suffix on their names, but maybe if we make sur=
e that the functionality is similar enough.</span><br></div><div><br></div>=
<div>I would like us to try to unite the terminology for one- and multidime=
nsional data, and I think that it would also be wise to go through the rang=
e() group writings to see if their modifiers can be extended to many dimens=
ions without compromising their efficiency or ease of use for the one dimen=
sional case. I have a hunch they can... at least the relevant ones. Then so=
me more are needed of course, such as transpose.</div><div><br></div><div>U=
nfortunately I don't have the google group for SG9 - Ranges, is there one y=
et?</div><div><br></div><div><br><br>Den fredagen den 7:e februari 2014 kl.=
 20:08:02 UTC+1 skrev Bengt Gustafsson:<blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr">Well, sparse matrices are another kind althogethe=
r. Of course they can get an array_view compatible API but that would be ve=
ry inefficient in real algorithms. I don't know much about this except that=
 they are usually designed so that serial access to elements from upper lef=
t is most efficient (they store basically the "next non-zero index and valu=
e" in two parallel arrays. Thus to make efficient use of them, as you wrote=
, requires alot of inside knowledge not in the regular array_view api.<div>=
<br></div><div>This seems to be akin to iterator categories. I don't think =
we have to worry about this, what can easily be added later is a traits sys=
tem so that you can detect whether something passed in as a array_view conc=
ept "compatible" object is actually a sparse matrix and some algorithms can=
 detect this (at compile time of course) and dispatch to a smarter implemen=
tation.</div><div><br></div><div>The other thing is the "mode" according to=
 your link, which tells the called function that the matrix is tirangular o=
r whatever, _without_ changing its class, that is, how elements are stored.=
 It is just a guarantee from the caller. Of course you could change the sto=
rage mode, but then we are in the category above that can be handled by tra=
its. The question here is whether we need runtime dispatch. I don't think s=
o. This means that it would be easy to device a triangular_array_view by ju=
st doing a "nop" subclassing. If many different modes are to be handled a "=
nop" template parameter can be introduced to trigger the traits class. I do=
n't see that this affects this proposal or that this warrants an extra Mode=
 template parameter on the "classic" array_view.</div><div><br></div><div>T=
his system would be orthogonal to whether the arrayts are fixed or dynamica=
lly sized.&nbsp;<br><br>Den fredagen den 7:e februari 2014 kl. 18:22:00 UTC=
+1 skrev Jesse Perla:<blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><br>On Thursday, February 6, 2014 2:58:29 PM UTC-8, Bengt Gustafsson wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Note that when =
I referred to triangular or sparse matrices I was talking about array_view =
as a concept, i.e. that when new algorithms are written and old code conver=
ted to have the "matrix" type as a template they are callable with anything=
 conforming to the "concept" array_view, such as some representation of a t=
riangular matrix. This would be some other class however, such as triangula=
r_matrix or something like that.<div><br></div></div></blockquote><div>Yup,=
 I think we are thinking the same thing. I guess what I was thinking was th=
at the array_view concept, may not be able to apply to both sparse and dens=
e, or the common elements of these might be small (getsize certainly is one=
 of them). &nbsp;This is a tough design decision that needs to figure out w=
hat operations sparse multi_array iterators might have.</div><div>&nbsp;</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div=
>My main point was that if the concept is ever to be useful for fixed size =
views the getsize() function must be different per dimension (So that some =
can be constexpr). As we don't know the number of dimensions the logical th=
ing to do is to</div><div>use a template&lt;int&gt; getsize() as the main a=
pi to get sizes. An auxiliary getsize(dim) can be built on top.<br></div></=
div></blockquote><div><br></div><div>One other comment on the fixed size (a=
nd potentially dynamic sized) that I just thought of. &nbsp;I am not sure h=
ow prevalent these are in the dynamic types (though Eigen seems to have lot=
s of it: <a href=3D"http://eigen.tuxfamily.org/dox/group__enums.html#gga0c5=
bde183ecefe103f70b49ad9740bcda02a97bb4792f98916a1156a521fa9813" target=3D"_=
blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F=
%2Feigen.tuxfamily.org%2Fdox%2Fgroup__enums.html%23gga0c5bde183ecefe103f70b=
49ad9740bcda02a97bb4792f98916a1156a521fa9813\46sa\75D\46sntz\0751\46usg\75A=
FQjCNFZpaDB3NI-EgRR1tIgAyI_8ZAJoA';return true;" onclick=3D"this.href=3D'ht=
tp://www.google.com/url?q\75http%3A%2F%2Feigen.tuxfamily.org%2Fdox%2Fgroup_=
_enums.html%23gga0c5bde183ecefe103f70b49ad9740bcda02a97bb4792f98916a1156a52=
1fa9813\46sa\75D\46sntz\0751\46usg\75AFQjCNFZpaDB3NI-EgRR1tIgAyI_8ZAJoA';re=
turn true;">http://eigen.tuxfamily.org/<wbr>dox/group__enums.html#<wbr>gga0=
c5bde183ecefe103f70b49ad97<wbr>40bcda02a97bb4792f98916a1156a5<wbr>21fa9813<=
/a>) , but they are all over the fixed size types</div><div><br></div><div>=
These things often use alignment tricks to get maximum efficiency (especial=
ly with SIMD). &nbsp;See the following on eigen:&nbsp;<a href=3D"http://www=
..mrpt.org/tutorials/programming/maths-and-geometry/matrices_vectors_arrays_=
and_linear_algebra_mrpt_and_eigen_classes/" target=3D"_blank" onmousedown=
=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.mrpt.org%2F=
tutorials%2Fprogramming%2Fmaths-and-geometry%2Fmatrices_vectors_arrays_and_=
linear_algebra_mrpt_and_eigen_classes%2F\46sa\75D\46sntz\0751\46usg\75AFQjC=
NERCHcOzzsUq44zMXb3qzCkv7JUMQ';return true;" onclick=3D"this.href=3D'http:/=
/www.google.com/url?q\75http%3A%2F%2Fwww.mrpt.org%2Ftutorials%2Fprogramming=
%2Fmaths-and-geometry%2Fmatrices_vectors_arrays_and_linear_algebra_mrpt_and=
_eigen_classes%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNERCHcOzzsUq44zMXb3qzCk=
v7JUMQ';return true;">http://www.mrpt.org/<wbr>tutorials/programming/maths-=
<wbr>and-geometry/matrices_vectors_<wbr>arrays_and_linear_algebra_<wbr>mrpt=
_and_eigen_classes/</a> &nbsp;and&nbsp;<a href=3D"http://eigen.tuxfamily.or=
g/dox-devel/group__DenseMatrixManipulation__Alignement.html" target=3D"_bla=
nk" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2F=
eigen.tuxfamily.org%2Fdox-devel%2Fgroup__DenseMatrixManipulation__Alignemen=
t.html\46sa\75D\46sntz\0751\46usg\75AFQjCNGxFgFoymgIsFG8RJO-v1k7Kg3xZw';ret=
urn true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F=
%2Feigen.tuxfamily.org%2Fdox-devel%2Fgroup__DenseMatrixManipulation__Aligne=
ment.html\46sa\75D\46sntz\0751\46usg\75AFQjCNGxFgFoymgIsFG8RJO-v1k7Kg3xZw';=
return true;">http://eigen.tuxfamily.<wbr>org/dox-devel/group__<wbr>DenseMa=
trixManipulation__<wbr>Alignement.html</a>&nbsp; &nbsp;as an example. &nbsp=
;Also see&nbsp;<a href=3D"http://viennacl.sourceforge.net/doc/classviennacl=
_1_1matrix.html" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.g=
oogle.com/url?q\75http%3A%2F%2Fviennacl.sourceforge.net%2Fdoc%2Fclassvienna=
cl_1_1matrix.html\46sa\75D\46sntz\0751\46usg\75AFQjCNFzQ-0gFIDT7FtrZsdbdgtc=
MgeAQg';return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\7=
5http%3A%2F%2Fviennacl.sourceforge.net%2Fdoc%2Fclassviennacl_1_1matrix.html=
\46sa\75D\46sntz\0751\46usg\75AFQjCNFzQ-0gFIDT7FtrZsdbdgtcMgeAQg';return tr=
ue;">http://viennacl.<wbr>sourceforge.net/doc/<wbr>classviennacl_1_1matrix.=
html</a>&nbsp; &nbsp; This is also used all over GPU programming, such as&n=
bsp;<a href=3D"http://stackoverflow.com/questions/13008096/aligning-gpu-mem=
ory-accesses-of-an-image-convolution-opencl-cuda-kernel" target=3D"_blank" =
onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fstac=
koverflow.com%2Fquestions%2F13008096%2Faligning-gpu-memory-accesses-of-an-i=
mage-convolution-opencl-cuda-kernel\46sa\75D\46sntz\0751\46usg\75AFQjCNEBMq=
LwjVHGcwlAuW-kR3JshWBvhQ';return true;" onclick=3D"this.href=3D'http://www.=
google.com/url?q\75http%3A%2F%2Fstackoverflow.com%2Fquestions%2F13008096%2F=
aligning-gpu-memory-accesses-of-an-image-convolution-opencl-cuda-kernel\46s=
a\75D\46sntz\0751\46usg\75AFQjCNEBMqLwjVHGcwlAuW-kR3JshWBvhQ';return true;"=
>http://stackoverflow.com/<wbr>questions/13008096/aligning-<wbr>gpu-memory-=
accesses-of-an-<wbr>image-convolution-opencl-cuda-<wbr>kernel</a>&nbsp; &nb=
sp; While this sort of interface may not directly work on GPUs (yet) &nbsp;=
 It is much more efficient to copy memory back and forth if you don't need =
to transform it every time to change the alignment.</div><div><br></div><di=
v>Since the primary reason to use fixed size arrays is efficiency and optim=
ization, interfacing with these sorts of views is first order. &nbsp;I susp=
ect that almost all small matrix/vector libraries use these tricks. &nbsp;T=
he alignment of a fixed_array_view would have to be a template parameter, a=
s it would change iterators and element acccess statically. &nbsp;This is w=
ay out of my pay grade to say much more on. &nbsp;My guess is that the SIMD=
 people would know a lot more:&nbsp;<a href=3D"http://www.open-std.org/jtc1=
/sc22/wg21/docs/papers/2013/n3759.html" target=3D"_blank" onmousedown=3D"th=
is.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjt=
c1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3759.html\46sa\75D\46sntz\0751\4=
6usg\75AFQjCNEqRDTG7ixBKCwgU37cQLMQP2i7Eg';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2F=
sc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3759.html\46sa\75D\46sntz\0751\46usg\=
75AFQjCNEqRDTG7ixBKCwgU37cQLMQP2i7Eg';return true;">http://www.open-std.org=
/<wbr>jtc1/sc22/wg21/docs/papers/<wbr>2013/n3759.html</a> &nbsp;and&nbsp;<a=
 href=3D"http://isocpp.org/files/papers/n3571.pdf" target=3D"_blank" onmous=
edown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fisocpp.org=
%2Ffiles%2Fpapers%2Fn3571.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNEFFddMJqPq=
bn_AZYXFdDaXo_j60g';return true;" onclick=3D"this.href=3D'http://www.google=
..com/url?q\75http%3A%2F%2Fisocpp.org%2Ffiles%2Fpapers%2Fn3571.pdf\46sa\75D\=
46sntz\0751\46usg\75AFQjCNEFFddMJqPqbn_AZYXFdDaXo_j60g';return true;">http:=
//isocpp.org/files/<wbr>papers/n3571.pdf</a> , Even if these proposals didn=
't go forward, thinking through this sort of integration is important befor=
e solidifying any fixed size interface.</div><div>&nbsp;</div><div><br></di=
v></div></blockquote></div></div></blockquote></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_2743_33301926.1391988658704--

.

------=_Part_365_12103768.1394632607610
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Now I have found some time to hack together some ideas regarding this.=20
Please read this new topic:

https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/hW2QAvmb=
oqU

The code is very preliminary, just to test if it was possible to make a=20
fixed/dynamic size matrix as one template class. It was...


Den m=C3=A5ndagen den 10:e februari 2014 kl. 00:30:58 UTC+1 skrev Bengt=20
Gustafsson:
>
> It suddenly struck me that we are basically trying to create=20
> multi-dimensional ranges. I have seen range-related suggestions to revers=
e=20
> ranges, take subranges, etc. which are essentially the one dimensional=20
> version of array slices, mirroring, etc. Of course transposition is not=
=20
> evident in one dimensional data for obvious reasons.
>
> As far as I know the range group is working with an idea of using the=20
> "pipe" concept of unix shell, so that you start with your source data and=
=20
> then apply modifiers, like so.
>
> for (auto x : my_vector | slice(0, 10) | reversed)
>    -- process 10 first elements backwards --;
>
> At the same time string_view is being designed, which is a kind of a rang=
e=20
> with extra APIs to mimic the API of std::string. Here the naming is the=
=20
> interesting part:
>
> A string_view is basically a view to a substring.
>
> An array_view is a way of specifying the dimensions and bounds of some=20
> data that is an adaptation of an one-dimensional dataset, such as a C arr=
ay=20
> or a vector. It can also be used to adapt non standard matrix types such =
as=20
> from Blitz++ or whatever library you have, given you can get the data=20
> pointer to the first element.
>
> This means that for strings a view is a "slice" while for arrays it is an=
=20
> adaptor of data type. I don't feel really comfortable with those differen=
t=20
> things having the same suffix on their names, but maybe if we make sure=
=20
> that the functionality is similar enough.
>
> I would like us to try to unite the terminology for one- and=20
> multidimensional data, and I think that it would also be wise to go throu=
gh=20
> the range() group writings to see if their modifiers can be extended to=
=20
> many dimensions without compromising their efficiency or ease of use for=
=20
> the one dimensional case. I have a hunch they can... at least the relevan=
t=20
> ones. Then some more are needed of course, such as transpose.
>
> Unfortunately I don't have the google group for SG9 - Ranges, is there on=
e=20
> yet?
>
>
>
> Den fredagen den 7:e februari 2014 kl. 20:08:02 UTC+1 skrev Bengt=20
> Gustafsson:
>>
>> Well, sparse matrices are another kind althogether. Of course they can=
=20
>> get an array_view compatible API but that would be very inefficient in r=
eal=20
>> algorithms. I don't know much about this except that they are usually=20
>> designed so that serial access to elements from upper left is most=20
>> efficient (they store basically the "next non-zero index and value" in t=
wo=20
>> parallel arrays. Thus to make efficient use of them, as you wrote, requi=
res=20
>> alot of inside knowledge not in the regular array_view api.
>>
>> This seems to be akin to iterator categories. I don't think we have to=
=20
>> worry about this, what can easily be added later is a traits system so t=
hat=20
>> you can detect whether something passed in as a array_view concept=20
>> "compatible" object is actually a sparse matrix and some algorithms can=
=20
>> detect this (at compile time of course) and dispatch to a smarter=20
>> implementation.
>>
>> The other thing is the "mode" according to your link, which tells the=20
>> called function that the matrix is tirangular or whatever, _without_=20
>> changing its class, that is, how elements are stored. It is just a=20
>> guarantee from the caller. Of course you could change the storage mode, =
but=20
>> then we are in the category above that can be handled by traits. The=20
>> question here is whether we need runtime dispatch. I don't think so. Thi=
s=20
>> means that it would be easy to device a triangular_array_view by just do=
ing=20
>> a "nop" subclassing. If many different modes are to be handled a "nop"=
=20
>> template parameter can be introduced to trigger the traits class. I don'=
t=20
>> see that this affects this proposal or that this warrants an extra Mode=
=20
>> template parameter on the "classic" array_view.
>>
>> This system would be orthogonal to whether the arrayts are fixed or=20
>> dynamically sized.=20
>>
>> Den fredagen den 7:e februari 2014 kl. 18:22:00 UTC+1 skrev Jesse Perla:
>>>
>>>
>>> On Thursday, February 6, 2014 2:58:29 PM UTC-8, Bengt Gustafsson wrote:
>>>>
>>>> Note that when I referred to triangular or sparse matrices I was=20
>>>> talking about array_view as a concept, i.e. that when new algorithms a=
re=20
>>>> written and old code converted to have the "matrix" type as a template=
 they=20
>>>> are callable with anything conforming to the "concept" array_view, suc=
h as=20
>>>> some representation of a triangular matrix. This would be some other c=
lass=20
>>>> however, such as triangular_matrix or something like that.
>>>>
>>>> Yup, I think we are thinking the same thing. I guess what I was=20
>>> thinking was that the array_view concept, may not be able to apply to b=
oth=20
>>> sparse and dense, or the common elements of these might be small (getsi=
ze=20
>>> certainly is one of them).  This is a tough design decision that needs =
to=20
>>> figure out what operations sparse multi_array iterators might have.
>>> =20
>>>
>>>> My main point was that if the concept is ever to be useful for fixed=
=20
>>>> size views the getsize() function must be different per dimension (So =
that=20
>>>> some can be constexpr). As we don't know the number of dimensions the=
=20
>>>> logical thing to do is to
>>>> use a template<int> getsize() as the main api to get sizes. An=20
>>>> auxiliary getsize(dim) can be built on top.
>>>>
>>>
>>> One other comment on the fixed size (and potentially dynamic sized) tha=
t=20
>>> I just thought of.  I am not sure how prevalent these are in the dynami=
c=20
>>> types (though Eigen seems to have lots of it:=20
>>> http://eigen.tuxfamily.org/dox/group__enums.html#gga0c5bde183ecefe103f7=
0b49ad9740bcda02a97bb4792f98916a1156a521fa9813)=20
>>> , but they are all over the fixed size types
>>>
>>> These things often use alignment tricks to get maximum efficiency=20
>>> (especially with SIMD).  See the following on eigen:=20
>>> http://www.mrpt.org/tutorials/programming/maths-and-geometry/matrices_v=
ectors_arrays_and_linear_algebra_mrpt_and_eigen_classes/ and=20
>>> http://eigen.tuxfamily.org/dox-devel/group__DenseMatrixManipulation__Al=
ignement.html =20
>>>  as an example.  Also see=20
>>> http://viennacl.sourceforge.net/doc/classviennacl_1_1matrix.html   =20
>>> This is also used all over GPU programming, such as=20
>>> http://stackoverflow.com/questions/13008096/aligning-gpu-memory-accesse=
s-of-an-image-convolution-opencl-cuda-kernel =20
>>>   While this sort of interface may not directly work on GPUs (yet)   It=
 is=20
>>> much more efficient to copy memory back and forth if you don't need to=
=20
>>> transform it every time to change the alignment.
>>>
>>> Since the primary reason to use fixed size arrays is efficiency and=20
>>> optimization, interfacing with these sorts of views is first order.  I=
=20
>>> suspect that almost all small matrix/vector libraries use these tricks.=
=20
>>>  The alignment of a fixed_array_view would have to be a template parame=
ter,=20
>>> as it would change iterators and element acccess statically.  This is w=
ay=20
>>> out of my pay grade to say much more on.  My guess is that the SIMD peo=
ple=20
>>> would know a lot more:=20
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3759.html  and=
=20
>>> http://isocpp.org/files/papers/n3571.pdf , Even if these proposals=20
>>> didn't go forward, thinking through this sort of integration is importa=
nt=20
>>> before solidifying any fixed size interface.
>>> =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_365_12103768.1394632607610
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Now I have found some time to hack together some ideas reg=
arding this. Please read this new topic:<div><br></div><div>https://groups.=
google.com/a/isocpp.org/forum/#!topic/std-proposals/hW2QAvmboqU</div><div><=
br></div><div>The code is very preliminary, just to test if it was possible=
 to make a fixed/dynamic size matrix as one template class. It was...</div>=
<div><br><br>Den m=C3=A5ndagen den 10:e februari 2014 kl. 00:30:58 UTC+1 sk=
rev Bengt Gustafsson:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">It suddenly struck me that we are basically trying to create multi=
-dimensional ranges. I have seen range-related suggestions to reverse range=
s, take subranges, etc. which are essentially the one dimensional version o=
f array slices, mirroring, etc. Of course transposition is not evident in o=
ne dimensional data for obvious reasons.<div><br></div><div>As far as I kno=
w the range group is working with an idea of using the "pipe" concept of un=
ix shell, so that you start with your source data and then apply modifiers,=
 like so.</div><div><br></div><div>for (auto x : my_vector | slice(0, 10) |=
 reversed)</div><div>&nbsp; &nbsp;-- process 10 first elements backwards --=
;</div><div><br></div><div>At the same time string_view is being designed, =
which is a kind of a range with extra APIs to mimic the API of std::string.=
 Here the naming is the interesting part:</div><div><br></div><div>A string=
_view is basically a view to a substring.</div><div><br></div><div>An array=
_view is a way of specifying the dimensions and bounds of some data that is=
 an adaptation of an one-dimensional dataset, such as a C array or a vector=
.. It can also be used to adapt non standard matrix types such as from Blitz=
++ or whatever library you have, given you can get the data pointer to the =
first element.</div><div><br></div><div><span style=3D"font-size:13px">This=
 means that for strings a view is a "slice" while for arrays it is an adapt=
or of data type. I don't feel really comfortable with those different thing=
s having the same suffix on their names, but maybe if we make sure that the=
 functionality is similar enough.</span><br></div><div><br></div><div>I wou=
ld like us to try to unite the terminology for one- and multidimensional da=
ta, and I think that it would also be wise to go through the range() group =
writings to see if their modifiers can be extended to many dimensions witho=
ut compromising their efficiency or ease of use for the one dimensional cas=
e. I have a hunch they can... at least the relevant ones. Then some more ar=
e needed of course, such as transpose.</div><div><br></div><div>Unfortunate=
ly I don't have the google group for SG9 - Ranges, is there one yet?</div><=
div><br></div><div><br><br>Den fredagen den 7:e februari 2014 kl. 20:08:02 =
UTC+1 skrev Bengt Gustafsson:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">Well, sparse matrices are another kind althogether. Of course th=
ey can get an array_view compatible API but that would be very inefficient =
in real algorithms. I don't know much about this except that they are usual=
ly designed so that serial access to elements from upper left is most effic=
ient (they store basically the "next non-zero index and value" in two paral=
lel arrays. Thus to make efficient use of them, as you wrote, requires alot=
 of inside knowledge not in the regular array_view api.<div><br></div><div>=
This seems to be akin to iterator categories. I don't think we have to worr=
y about this, what can easily be added later is a traits system so that you=
 can detect whether something passed in as a array_view concept "compatible=
" object is actually a sparse matrix and some algorithms can detect this (a=
t compile time of course) and dispatch to a smarter implementation.</div><d=
iv><br></div><div>The other thing is the "mode" according to your link, whi=
ch tells the called function that the matrix is tirangular or whatever, _wi=
thout_ changing its class, that is, how elements are stored. It is just a g=
uarantee from the caller. Of course you could change the storage mode, but =
then we are in the category above that can be handled by traits. The questi=
on here is whether we need runtime dispatch. I don't think so. This means t=
hat it would be easy to device a triangular_array_view by just doing a "nop=
" subclassing. If many different modes are to be handled a "nop" template p=
arameter can be introduced to trigger the traits class. I don't see that th=
is affects this proposal or that this warrants an extra Mode template param=
eter on the "classic" array_view.</div><div><br></div><div>This system woul=
d be orthogonal to whether the arrayts are fixed or dynamically sized.&nbsp=
;<br><br>Den fredagen den 7:e februari 2014 kl. 18:22:00 UTC+1 skrev Jesse =
Perla:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>On Thurs=
day, February 6, 2014 2:58:29 PM UTC-8, Bengt Gustafsson wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr">Note that when I referred to t=
riangular or sparse matrices I was talking about array_view as a concept, i=
..e. that when new algorithms are written and old code converted to have the=
 "matrix" type as a template they are callable with anything conforming to =
the "concept" array_view, such as some representation of a triangular matri=
x. This would be some other class however, such as triangular_matrix or som=
ething like that.<div><br></div></div></blockquote><div>Yup, I think we are=
 thinking the same thing. I guess what I was thinking was that the array_vi=
ew concept, may not be able to apply to both sparse and dense, or the commo=
n elements of these might be small (getsize certainly is one of them). &nbs=
p;This is a tough design decision that needs to figure out what operations =
sparse multi_array iterators might have.</div><div>&nbsp;</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>My main point =
was that if the concept is ever to be useful for fixed size views the getsi=
ze() function must be different per dimension (So that some can be constexp=
r). As we don't know the number of dimensions the logical thing to do is to=
</div><div>use a template&lt;int&gt; getsize() as the main api to get sizes=
.. An auxiliary getsize(dim) can be built on top.<br></div></div></blockquot=
e><div><br></div><div>One other comment on the fixed size (and potentially =
dynamic sized) that I just thought of. &nbsp;I am not sure how prevalent th=
ese are in the dynamic types (though Eigen seems to have lots of it: <a hre=
f=3D"http://eigen.tuxfamily.org/dox/group__enums.html#gga0c5bde183ecefe103f=
70b49ad9740bcda02a97bb4792f98916a1156a521fa9813" target=3D"_blank" onmoused=
own=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Feigen.tuxfam=
ily.org%2Fdox%2Fgroup__enums.html%23gga0c5bde183ecefe103f70b49ad9740bcda02a=
97bb4792f98916a1156a521fa9813\46sa\75D\46sntz\0751\46usg\75AFQjCNFZpaDB3NI-=
EgRR1tIgAyI_8ZAJoA';return true;" onclick=3D"this.href=3D'http://www.google=
..com/url?q\75http%3A%2F%2Feigen.tuxfamily.org%2Fdox%2Fgroup__enums.html%23g=
ga0c5bde183ecefe103f70b49ad9740bcda02a97bb4792f98916a1156a521fa9813\46sa\75=
D\46sntz\0751\46usg\75AFQjCNFZpaDB3NI-EgRR1tIgAyI_8ZAJoA';return true;">htt=
p://eigen.tuxfamily.org/<wbr>dox/group__enums.html#<wbr>gga0c5bde183ecefe10=
3f70b49ad97<wbr>40bcda02a97bb4792f98916a1156a5<wbr>21fa9813</a>) , but they=
 are all over the fixed size types</div><div><br></div><div>These things of=
ten use alignment tricks to get maximum efficiency (especially with SIMD). =
&nbsp;See the following on eigen:&nbsp;<a href=3D"http://www.mrpt.org/tutor=
ials/programming/maths-and-geometry/matrices_vectors_arrays_and_linear_alge=
bra_mrpt_and_eigen_classes/" target=3D"_blank" onmousedown=3D"this.href=3D'=
http://www.google.com/url?q\75http%3A%2F%2Fwww.mrpt.org%2Ftutorials%2Fprogr=
amming%2Fmaths-and-geometry%2Fmatrices_vectors_arrays_and_linear_algebra_mr=
pt_and_eigen_classes%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNERCHcOzzsUq44zMX=
b3qzCkv7JUMQ';return true;" onclick=3D"this.href=3D'http://www.google.com/u=
rl?q\75http%3A%2F%2Fwww.mrpt.org%2Ftutorials%2Fprogramming%2Fmaths-and-geom=
etry%2Fmatrices_vectors_arrays_and_linear_algebra_mrpt_and_eigen_classes%2F=
\46sa\75D\46sntz\0751\46usg\75AFQjCNERCHcOzzsUq44zMXb3qzCkv7JUMQ';return tr=
ue;">http://www.mrpt.org/<wbr>tutorials/programming/maths-<wbr>and-geometry=
/matrices_vectors_<wbr>arrays_and_linear_algebra_<wbr>mrpt_and_eigen_classe=
s/</a> &nbsp;and&nbsp;<a href=3D"http://eigen.tuxfamily.org/dox-devel/group=
__DenseMatrixManipulation__Alignement.html" target=3D"_blank" onmousedown=
=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Feigen.tuxfamily=
..org%2Fdox-devel%2Fgroup__DenseMatrixManipulation__Alignement.html\46sa\75D=
\46sntz\0751\46usg\75AFQjCNGxFgFoymgIsFG8RJO-v1k7Kg3xZw';return true;" oncl=
ick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Feigen.tuxfam=
ily.org%2Fdox-devel%2Fgroup__DenseMatrixManipulation__Alignement.html\46sa\=
75D\46sntz\0751\46usg\75AFQjCNGxFgFoymgIsFG8RJO-v1k7Kg3xZw';return true;">h=
ttp://eigen.tuxfamily.<wbr>org/dox-devel/group__<wbr>DenseMatrixManipulatio=
n__<wbr>Alignement.html</a>&nbsp; &nbsp;as an example. &nbsp;Also see&nbsp;=
<a href=3D"http://viennacl.sourceforge.net/doc/classviennacl_1_1matrix.html=
" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q=
\75http%3A%2F%2Fviennacl.sourceforge.net%2Fdoc%2Fclassviennacl_1_1matrix.ht=
ml\46sa\75D\46sntz\0751\46usg\75AFQjCNFzQ-0gFIDT7FtrZsdbdgtcMgeAQg';return =
true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fv=
iennacl.sourceforge.net%2Fdoc%2Fclassviennacl_1_1matrix.html\46sa\75D\46snt=
z\0751\46usg\75AFQjCNFzQ-0gFIDT7FtrZsdbdgtcMgeAQg';return true;">http://vie=
nnacl.<wbr>sourceforge.net/doc/<wbr>classviennacl_1_1matrix.html</a>&nbsp; =
&nbsp; This is also used all over GPU programming, such as&nbsp;<a href=3D"=
http://stackoverflow.com/questions/13008096/aligning-gpu-memory-accesses-of=
-an-image-convolution-opencl-cuda-kernel" target=3D"_blank" onmousedown=3D"=
this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fstackoverflow.com%2=
Fquestions%2F13008096%2Faligning-gpu-memory-accesses-of-an-image-convolutio=
n-opencl-cuda-kernel\46sa\75D\46sntz\0751\46usg\75AFQjCNEBMqLwjVHGcwlAuW-kR=
3JshWBvhQ';return true;" onclick=3D"this.href=3D'http://www.google.com/url?=
q\75http%3A%2F%2Fstackoverflow.com%2Fquestions%2F13008096%2Faligning-gpu-me=
mory-accesses-of-an-image-convolution-opencl-cuda-kernel\46sa\75D\46sntz\07=
51\46usg\75AFQjCNEBMqLwjVHGcwlAuW-kR3JshWBvhQ';return true;">http://stackov=
erflow.com/<wbr>questions/13008096/aligning-<wbr>gpu-memory-accesses-of-an-=
<wbr>image-convolution-opencl-cuda-<wbr>kernel</a>&nbsp; &nbsp; While this =
sort of interface may not directly work on GPUs (yet) &nbsp; It is much mor=
e efficient to copy memory back and forth if you don't need to transform it=
 every time to change the alignment.</div><div><br></div><div>Since the pri=
mary reason to use fixed size arrays is efficiency and optimization, interf=
acing with these sorts of views is first order. &nbsp;I suspect that almost=
 all small matrix/vector libraries use these tricks. &nbsp;The alignment of=
 a fixed_array_view would have to be a template parameter, as it would chan=
ge iterators and element acccess statically. &nbsp;This is way out of my pa=
y grade to say much more on. &nbsp;My guess is that the SIMD people would k=
now a lot more:&nbsp;<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs=
/papers/2013/n3759.html" target=3D"_blank" onmousedown=3D"this.href=3D'http=
://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg2=
1%2Fdocs%2Fpapers%2F2013%2Fn3759.html\46sa\75D\46sntz\0751\46usg\75AFQjCNEq=
RDTG7ixBKCwgU37cQLMQP2i7Eg';return true;" onclick=3D"this.href=3D'http://ww=
w.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fd=
ocs%2Fpapers%2F2013%2Fn3759.html\46sa\75D\46sntz\0751\46usg\75AFQjCNEqRDTG7=
ixBKCwgU37cQLMQP2i7Eg';return true;">http://www.open-std.org/<wbr>jtc1/sc22=
/wg21/docs/papers/<wbr>2013/n3759.html</a> &nbsp;and&nbsp;<a href=3D"http:/=
/isocpp.org/files/papers/n3571.pdf" target=3D"_blank" onmousedown=3D"this.h=
ref=3D'http://www.google.com/url?q\75http%3A%2F%2Fisocpp.org%2Ffiles%2Fpape=
rs%2Fn3571.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNEFFddMJqPqbn_AZYXFdDaXo_j=
60g';return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75ht=
tp%3A%2F%2Fisocpp.org%2Ffiles%2Fpapers%2Fn3571.pdf\46sa\75D\46sntz\0751\46u=
sg\75AFQjCNEFFddMJqPqbn_AZYXFdDaXo_j60g';return true;">http://isocpp.org/fi=
les/<wbr>papers/n3571.pdf</a> , Even if these proposals didn't go forward, =
thinking through this sort of integration is important before solidifying a=
ny fixed size interface.</div><div>&nbsp;</div><div><br></div></div></block=
quote></div></div></blockquote></div></div></blockquote></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_365_12103768.1394632607610--

.