------=_Part_557_1620785.1394630631025
Content-Type: text/plain; charset=UTF-8

Here is a first sketch on a proposal for multi-dimensional data
handling in C++. It consists of two main parts: The storage itself
and adapters to view the storage in different ways.

This work was inspired by the array_view proposal. While array_view
can be used to get a n-dimensional view of some 1D container's data I
felt it was strange that there was no direct way to create a
n-dimensional container.

Another motivator is that for performance reasons it is an advantage to
make
use of fixed dimensions whenever possible. This proposal allows free mixing
of
fixed and variable dimensions in a way so that (generic) functions will be
automatically optimized for each case.


*Arrays*

The basis for storage is the idea to extend the current std::array
template in two ways.

Firstly to allow more than one dimension by replacing the size template
parameter with a parameter pack:

template<typename T, size_t... Ss> class array;


Secondly to allow arrays to be dynamically sized at constructor time
for those dimensions marked with the var_dim value:

static const size_t var_dim = -1;


For instance a 3 times n array is declared like this:

std::array<3, var_dim> my_array(3, n);


A first implementation of this type of array is available at:
(www.beamways.com/file/array_proposal_v1.zip). I have tested this with VS
2013.


*Adapters*

Adapters are very similar to what the Range working group is looking
at, but for the multi-dimensional case. The proposals would have to
be synchronized partly due to naming issues and more importantly as
these adapters also work for 1-d case and thus generalizes the Range
idea.

So far I have not implemented this for real, but there is embryotic
code in the same file. As it is currently commented out I am sure it
is full of typos.

The idea of piping using operator| to combine different adaptors is
employed.


The adapters I have thought of so far are:

reverse - Let a set dimension go backwards.
transpose - Swap two dimensions.
slice - Cut out a hyper-rectangle, could be extended by stride handling.
bind - Bind one dimension to a value, reducing dimensionality.
offset - Adjust start index in any dimension.
cast - View the data using a totally different set of dimensions.

Adapters are not tightly connected with the new array class, but use
it as a concept for the base data they adapt, themselves providing
the same API for direct use or further adaptation.


Algorithms for working on matrix data are plentiful but are excluded
from this proposal for the time being, barring a simple matrix
multiply which is included as an example.


A longer text about this proposal is available here:
www.beamways.com/file/array_proposal_v1.zip

--

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

<div dir=3D"ltr"><div><div><span style=3D"font-size: 13px;">Here is a first=
 sketch on a proposal for multi-dimensional data</span><br></div><div>handl=
ing in C++. It consists of two main parts: The storage itself</div><div>and=
 adapters to view the storage in different ways.</div><div><br></div><div>T=
his work was inspired by the array_view proposal. While array_view</div><di=
v>can be used to get a n-dimensional view of some 1D container's data I</di=
v><div>felt it was strange that there was no direct way to create a</div><d=
iv>n-dimensional container.</div><div><br></div><div>Another motivator is t=
hat for performance reasons it is an advantage to make&nbsp;</div><div>use =
of fixed dimensions whenever possible. This proposal allows free mixing of<=
/div><div>fixed and variable dimensions in a way so that (generic) function=
s will be</div><div>automatically optimized for each case.</div><div><br></=
div><div><br></div><div><b>Arrays</b></div><div><br></div><div>The basis fo=
r storage is the idea to extend the current std::array</div><div>template i=
n two ways.&nbsp;</div><div><br></div><div>Firstly to allow more than one d=
imension by&nbsp;<span style=3D"font-size: 13px;">replacing the size templa=
te&nbsp;</span></div><div><span style=3D"font-size: 13px;">parameter with a=
 parameter pack:</span></div><div><br></div><div><div class=3D"prettyprint"=
 style=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb(187, =
187, 187); word-wrap: break-word;"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">template</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">typen=
ame</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> size_t</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">...</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606=
;" class=3D"styled-by-prettify">Ss</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">class</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> array</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
;</span></div></code></div><br></div><div><br></div><div>Secondly to allow =
arrays to be dynamically sized at constructor time</div><div>for those dime=
nsions marked with the var_dim value:</div><div><br></div><div><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border: 1px=
 solid rgb(187, 187, 187); word-wrap: break-word;"><code class=3D"prettypri=
nt"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">static</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
size_t var_dim </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">-</span><sp=
an style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span></div></code></div><=
br></div><div><br></div><div>For instance a 3 times n array is declared lik=
e this:</div><div><br></div><div><div class=3D"prettyprint" style=3D"backgr=
ound-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-=
wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint=
"><span style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">array</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: =
#066;" class=3D"styled-by-prettify">3</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> var_dim</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> my_array</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: #066;" class=3D"styled-by-prettify">=
3</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> n</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">);</span></div></code></di=
v><br></div><div><br></div><div>A first implementation of this type of arra=
y is available at:</div><div>(<a href=3D"http://www.beamways.com/file/array=
_proposal_v1.zip">www.beamways.com/file/array_proposal_v1.zip</a>). I have =
tested this with VS 2013.</div><div><br></div><div><br></div><div><b>Adapte=
rs</b></div><div><br></div><div>Adapters are very similar to what the Range=
 working group is looking</div><div>at, but for the multi-dimensional case.=
 The proposals would have to</div><div>be synchronized partly due to naming=
 issues and more importantly as</div><div>these adapters also work for 1-d =
case and thus generalizes the Range</div><div>idea.</div><div><br></div><di=
v>So far I have not implemented this for real, but there is embryotic</div>=
<div>code in the same file. As it is currently commented out I am sure it</=
div><div>is full of typos.</div><div><br></div><div>The idea of piping usin=
g operator| to combine different adaptors is employed.</div><div><br></div>=
<div><br></div><div>The adapters I have thought of so far are:</div><div><b=
r></div><div>reverse<span class=3D"Apple-tab-span" style=3D"white-space:pre=
">  </span>- Let a set dimension go backwards.</div><div>transpose<span cla=
ss=3D"Apple-tab-span" style=3D"white-space:pre">  </span>- Swap two dimensi=
ons.</div><div>slice<span class=3D"Apple-tab-span" style=3D"white-space:pre=
">   </span>- Cut out a hyper-rectangle, could be extended by stride handli=
ng.</div><div>bind<span class=3D"Apple-tab-span" style=3D"white-space:pre">=
   </span>- Bind one dimension to a value, reducing dimensionality.</div><d=
iv>offset<span class=3D"Apple-tab-span" style=3D"white-space:pre">  </span>=
- Adjust start index in any dimension.</div><div>cast<span class=3D"Apple-t=
ab-span" style=3D"white-space:pre">   </span>- View the data using a totall=
y different set of dimensions.</div><div><br></div><div>Adapters are not ti=
ghtly connected with the new array class, but use</div><div>it as a concept=
 for the base data they adapt, themselves providing</div><div>the same API =
for direct use or further adaptation.</div><div><br></div><div><br></div><d=
iv>Algorithms for working on matrix data are plentiful but are excluded</di=
v><div>from this proposal for the time being, barring a simple matrix</div>=
<div>multiply which is included as an example.</div><div><br></div><div><br=
></div><div>A longer text about this proposal is available here:</div><div>=
<a href=3D"http://www.beamways.com/file/array_proposal_v1.zip">www.beamways=
..com/file/array_proposal_v1.zip</a></div></div><div><br></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_557_1620785.1394630631025--

.

------=_Part_18_15580934.1394645275519
Content-Type: text/plain; charset=UTF-8


On Wednesday, March 12, 2014 6:23:51 AM UTC-7, Bengt Gustafsson wrote:
>
> Another motivator is that for performance reasons it is an advantage to
> make
> use of fixed dimensions whenever possible. This proposal allows free
> mixing of
> fixed and variable dimensions in a way so that (generic) functions will be
> automatically optimized for each case.
>
>
I am not sure that it is worth the effort to have them in the same class,
especially since you would have to deal with differences in the concepts
they implement (e.g., no resize with fixed)..  Having separate fixed vs.
variable storage classes seems reasonable(though Eigen did put them both
together, it looks ugly:
http://eigen.tuxfamily.org/dox/classEigen_1_1DenseBase.html#a1be3860693af99a6c1da72580097294ca38ab482a62bf46f6ed6dcc4e9dd0dddf)
..  If you are doing a free form fixed and variable version in the same
class, make sure that there is a static query to determine if it is 100%
fixed size, which is necessary for interfacing with certain external
libraries.

The other thing is: for all the reasons I mentioned before, we need to have
column vs. row storage ordering as part of the class or it is useless for
scientific work.  This should be a global, static setting defaulting to
row-major.

--

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

<div dir=3D"ltr"><br>On Wednesday, March 12, 2014 6:23:51 AM UTC-7, Bengt G=
ustafsson 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"lt=
r"><div><div>Another motivator is that for performance reasons it is an adv=
antage to make&nbsp;<br></div><div>use of fixed dimensions whenever possibl=
e. This proposal allows free mixing of</div><div>fixed and variable dimensi=
ons in a way so that (generic) functions will be</div><div>automatically op=
timized for each case.</div><div><br></div></div></div></blockquote><div><b=
r></div><div><span>I am not sure that it is worth the effort to have them i=
n the same class, especially since you would have to deal with differences =
in the concepts they implement (e.g., no resize with fixed).. &nbsp;Having =
separate fixed vs. variable storage classes seems reasonable(though Eigen d=
id put them both together, it looks ugly: <a class=3D"linkclass" href=3D"ht=
tp://eigen.tuxfamily.org/dox/classEigen_1_1DenseBase.html#a1be3860693af99a6=
c1da72580097294ca38ab482a62bf46f6ed6dcc4e9dd0dddf">http://eigen.tuxfamily.o=
rg/dox/classEigen_1_1DenseBase.html#a1be3860693af99a6c1da72580097294ca38ab4=
82a62bf46f6ed6dcc4e9dd0dddf</a>) . &nbsp;If you are doing a free form fixed=
 and variable version in the same class, make sure that there is a static q=
uery to determine if it is 100% fixed size, which is necessary for interfac=
ing with certain external libraries.</span></div><div><br></div><div>The ot=
her thing is: for all the reasons I mentioned before, we need to have colum=
n vs. row storage ordering as part of the class or it is useless for scient=
ific work. &nbsp;This should be a global, static setting defaulting to row-=
major.</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_18_15580934.1394645275519--

.

------=_Part_2426_17901474.1394749041108
Content-Type: text/plain; charset=UTF-8


>
>
>> I am not sure that it is worth the effort to have them in the same class,
> especially since you would have to deal with differences in the concepts
> they implement (e.g., no resize with fixed)..  Having separate fixed vs.
> variable storage classes seems reasonable(though Eigen did put them both
> together, it looks ugly:
> http://eigen.tuxfamily.org/dox/classEigen_1_1DenseBase.html#a1be3860693af99a6c1da72580097294ca38ab482a62bf46f6ed6dcc4e9dd0dddf)
> .  If you are doing a free form fixed and variable version in the same
> class, make sure that there is a static query to determine if it is 100%
> fixed size, which is necessary for interfacing with certain external
> libraries.
>
> I am not aiming at post-construction variable size, only compile time vs
construction time size setting. Thus no resize() either way. I don't see
how an external library could care about this difference. However, I
noticed now that Eigen has the same idea of a "dynamic" size value, so at
least this concept has been tried before. I don't think their matrix class
looks particulrly ugly. And they provide typedefs for the most common sizes.

It could have some value to have a query for 100% fixed size as you said,
but not a very high value I would say.


> The other thing is: for all the reasons I mentioned before, we need to
> have column vs. row storage ordering as part of the class or it is useless
> for scientific work.  This should be a global, static setting defaulting to
> row-major.
>

The s_array feature provides this possibility (although not really fleshed
out yet). I'm totally against global static settings whatever they are for.
Especially in this case it depends so much on what algorithms you intend to
run on the data. These arrays are also not limited to two dimensions so
there
is not much value in discussing dimensions as rows and columns.

One thing I see now is that I may have focussed to much on the generic
programming side of this. Actually with this type of template based classes
there is no way to make more complex algorithms such as equation system
solvers non-templated and placed in cpp files. To allow any array-concept
compliant container a viable parameter to such a function would require
some type of adapter, probably with a stride for each dimension stored
(virtual operator() is too slow). I think this type of thinking may be the
reason to put such emphasis on row-major, while I was thinking in terms of
generic algorithms which get code-generated for each combination of arrays
they are used for (such as my multiplty example).

As far as I can see right now it should be quite easy to create an
interface class with these properties that can be created from any adapted
array (i.e. all of the adapters can work out the contents of the stride
vector amongst them).

Of course for the 2D case the normal would be to have just one stride (the
other stride assumed to be 1). If algorithms were to assume this they would
of course put limitations on the storage format of the data they operate
on. Overloading them on two types of parameters would suffice to handle
this, which brings us back to the original array_view/stride_array_view way
of thinking, I guess. Somehow it must be made clear to the compiler that
array_view is "better" than stride_array_view if both are possible. I guess
one possibility would be to have array_view be a base class of
stride_array_view (for the same template parameters). This would allow the
more efficent implementation to be selected. This comes with a combinatoric
explosion if there are multiple matrix parameters of course, but this is
only a matter of instantiating the same template explicitly for a few cases
(assuming you want to keep the implementation in a cpp file).

--

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

<div dir=3D"ltr"><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"><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"><div><div><br>=
</div></div></div></blockquote><div><span>I am not sure that it is worth th=
e effort to have them in the same class, especially since you would have to=
 deal with differences in the concepts they implement (e.g., no resize with=
 fixed).. &nbsp;Having separate fixed vs. variable storage classes seems re=
asonable(though Eigen did put them both together, it looks ugly: <a href=3D=
"http://eigen.tuxfamily.org/dox/classEigen_1_1DenseBase.html#a1be3860693af9=
9a6c1da72580097294ca38ab482a62bf46f6ed6dcc4e9dd0dddf" target=3D"_blank" onm=
ousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Feigen.t=
uxfamily.org%2Fdox%2FclassEigen_1_1DenseBase.html%23a1be3860693af99a6c1da72=
580097294ca38ab482a62bf46f6ed6dcc4e9dd0dddf\46sa\75D\46sntz\0751\46usg\75AF=
QjCNFmh4TZAW3Bb3VUyEGxGIfH7VdDvw';return true;" onclick=3D"this.href=3D'htt=
p://www.google.com/url?q\75http%3A%2F%2Feigen.tuxfamily.org%2Fdox%2FclassEi=
gen_1_1DenseBase.html%23a1be3860693af99a6c1da72580097294ca38ab482a62bf46f6e=
d6dcc4e9dd0dddf\46sa\75D\46sntz\0751\46usg\75AFQjCNFmh4TZAW3Bb3VUyEGxGIfH7V=
dDvw';return true;">http://eigen.tuxfamily.org/<wbr>dox/classEigen_1_1Dense=
Base.<wbr>html#<wbr>a1be3860693af99a6c1da725800972<wbr>94ca38ab482a62bf46f6=
ed6dcc4e9d<wbr>d0dddf</a>) . &nbsp;If you are doing a free form fixed and v=
ariable version in the same class, make sure that there is a static query t=
o determine if it is 100% fixed size, which is necessary for interfacing wi=
th certain external libraries.</span></div><div><br></div></div></blockquot=
e><div>I am not aiming at post-construction variable size, only compile tim=
e vs construction time size setting. Thus no resize() either way.&nbsp;<spa=
n style=3D"font-size: 13px;">I don't see how an external library could care=
 about this difference. However, I noticed now that Eigen has the same idea=
 of a "dynamic" size value, so at least this concept has been tried before.=
 I don't think their matrix class looks particulrly ugly. And they provide =
typedefs for the most common sizes.</span></div><div><br></div><div>It coul=
d have some value to have a query for 100% fixed size as you said, but not =
a very high value I would say.</div><div>&nbsp;</div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>The other thing is:=
 for all the reasons I mentioned before, we need to have column vs. row sto=
rage ordering as part of the class or it is useless for scientific work. &n=
bsp;This should be a global, static setting defaulting to row-major.</div><=
/div></blockquote><div><br></div><div>The s_array feature provides this pos=
sibility (although not really fleshed out yet). I'm totally against global =
static settings whatever they are for. Especially in this case it depends s=
o much on what algorithms you intend to run on the data. These arrays are a=
lso not limited to two dimensions so there</div><div>is not much value in d=
iscussing dimensions as rows and columns.</div><div>&nbsp;</div><div>One th=
ing I see now is that I may have focussed to much on the generic programmin=
g side of this. Actually with this type of template based classes there is =
no way to make more complex algorithms such as equation system solvers non-=
templated and placed in cpp files. To allow any array-concept compliant con=
tainer a viable parameter to such a function would require some type of ada=
pter, probably with a stride for each dimension stored (virtual operator() =
is too slow). I think this type of thinking may be the reason to put such e=
mphasis on row-major, while I was thinking in terms of generic algorithms w=
hich get code-generated for each combination of arrays they are used for (s=
uch as my multiplty example).</div><div><br></div><div>As far as I can see =
right now it should be quite easy to create an interface class with these p=
roperties that can be created from any adapted array (i.e. all of the adapt=
ers can work out the contents of the stride vector amongst them).&nbsp;</di=
v><div><br></div><div>Of course for the 2D case the normal would be to have=
 just one stride (the other stride assumed to be 1). If algorithms were to =
assume this they would of course put limitations on the storage format of t=
he data they operate on. Overloading them on two types of parameters would =
suffice to handle this, which brings us back to the original array_view/str=
ide_array_view way of thinking, I guess. Somehow it must be made clear to t=
he compiler that array_view is "better" than stride_array_view if both are =
possible. I guess one possibility would be to have array_view be a base cla=
ss of stride_array_view (for the same template parameters). This would allo=
w the more efficent implementation to be selected. This comes with a combin=
atoric explosion if there are multiple matrix parameters of course, but thi=
s is only a matter of instantiating the same template explicitly for a few =
cases (assuming you want to keep the implementation in a cpp file).</div><d=
iv><br></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_2426_17901474.1394749041108--

.

------=_Part_574_803197378.1427306033063
Content-Type: multipart/alternative;
 boundary="----=_Part_575_256127004.1427306033063"

------=_Part_575_256127004.1427306033063
Content-Type: text/plain; charset=UTF-8

This functionality would be really useful.

Has there been any further progress with this?

--

---
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_575_256127004.1427306033063
Content-Type: text/html; charset=UTF-8

<div dir="ltr">This functionality would be really useful.<div><br></div><div>Has there been any further progress with this?</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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_575_256127004.1427306033063--
------=_Part_574_803197378.1427306033063--

.

------=_Part_470_1673612214.1442935653127
Content-Type: multipart/alternative;
 boundary="----=_Part_471_1476777167.1442935653127"

------=_Part_471_1476777167.1442935653127
Content-Type: text/plain; charset=UTF-8

This proposal has two aspects:

1) Extending std::array for multiple dimensions.
This is exactly what N3851 proposes to solve, albeit in a more elegant and
general way than this proposal.

2) Allowing dynamic sizes in std::array.
The rationale of the std::array class is that it encapsulates fixed size
arrays. As such I believe that this proposal to allow dynamically sized
dimensions breaks the rationale of the class as it is.

P.S.
Multidimensional fixed arrays (1 above) can readily be achieved today by
nesting std::arrays. Like so:

    std::array<std::array<double, 4>, 3> v; // Row major 3x4 or column
major 4x3 depending on interpretation.

The memory is contiguous and access is fast, sizes are fixed so the
compiler will generate fast code. In fact I just checked with GCC 4.8.1
comparing nested std::array to std::array with typical 2d indexing (which
has to be considered the fastest case): http://goo.gl/t8k8CF the generated
code for both functions is the same, instruction for instruction (only some
offsets differ). That is good enough for me. I'm sure some one can come up
with some template magic to define multi_array as recursively nested
std::arrays.

--

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

<div dir=3D"ltr"><div>This proposal has two aspects:</div><div><br></div><d=
iv>1) Extending std::array for multiple dimensions.</div><div>This is exact=
ly what N3851 proposes to solve, albeit in a more elegant and general way t=
han this proposal.</div><div><br></div><div>2) Allowing dynamic sizes in st=
d::array.</div><div>The rationale of the std::array class is that it encaps=
ulates fixed size arrays. As such I believe that this proposal to allow dyn=
amically sized dimensions breaks the rationale of the class as it is.</div>=
<div><br></div><div>P.S.</div><div><div>Multidimensional fixed arrays (1 ab=
ove) can readily be achieved today by nesting std::arrays. Like so:=C2=A0</=
div><div><br></div><div><div>=C2=A0 =C2=A0 std::array&lt;std::array&lt;doub=
le, 4&gt;, 3&gt; v; // Row major 3x4 or column major 4x3 depending on inter=
pretation.</div><div>=C2=A0 =C2=A0=C2=A0</div></div><div>The memory is cont=
iguous and access is fast, sizes are fixed so the compiler will generate fa=
st code. In fact I just checked with GCC 4.8.1 comparing nested std::array =
to std::array with typical 2d indexing (which has to be considered the fast=
est case): http://goo.gl/t8k8CF the generated code for both functions is th=
e same, instruction for instruction (only some offsets differ). That is goo=
d enough for me. I&#39;m sure some one can come up with some template magic=
 to define multi_array as recursively nested std::arrays.</div><div><br></d=
iv></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_471_1476777167.1442935653127--
------=_Part_470_1673612214.1442935653127--

.

--001a1134beb256490d052059c811
Content-Type: text/plain; charset=UTF-8

On Tue, Sep 22, 2015 at 8:27 AM, <lenkkix@gmail.com> wrote:
>
> Multidimensional fixed arrays (1 above) can readily be achieved today by
> nesting std::arrays. Like so:
>
>     std::array<std::array<double, 4>, 3> v; // Row major 3x4 or column
> major 4x3 depending on interpretation.
>
> The memory is contiguous and access is fast, sizes are fixed so the
> compiler will generate fast code
>

Not exactly. When you make an array like that, while it is contiguous by
some definition of contiguous, there can be padding between the rows. For
some applications this may be fine, but if you need to interact with an API
that requires the array to truly have all of its elements contiguous, as it
would be with a real multidimensional array, then this is not sufficient.
Directly and properly supporting multiple dimensions can solve this problem.

--

---
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/.

--001a1134beb256490d052059c811
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Sep 22, 2015 at 8:27 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:lenkk=
ix@gmail.com" target=3D"_blank">lenkkix@gmail.com</a>&gt;</span> wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>Multidimensional fixe=
d arrays (1 above) can readily be achieved today by nesting std::arrays. Li=
ke so:=C2=A0</div><div><br></div><div><div>=C2=A0 =C2=A0 std::array&lt;std:=
:array&lt;double, 4&gt;, 3&gt; v; // Row major 3x4 or column major 4x3 depe=
nding on interpretation.</div><div>=C2=A0 =C2=A0=C2=A0</div></div><div>The =
memory is contiguous and access is fast, sizes are fixed so the compiler wi=
ll generate fast code</div></div></div></blockquote><div><br></div><div>Not=
 exactly. When you make an array like that, while it is contiguous by some =
definition of contiguous, there can be padding between the rows. For some a=
pplications this may be fine, but if you need to interact with an API that =
requires the array to truly have all of its elements contiguous, as it woul=
d be with a real multidimensional array, then this is not sufficient. Direc=
tly and properly supporting multiple dimensions can solve this problem.</di=
v></div></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 />

--001a1134beb256490d052059c811--

.

--089e01227f36a25b9a05205c4c1c
Content-Type: text/plain; charset=UTF-8

Padding between rows is what stride attributes are for. Even so a linear
vector or array backing a array_view solves the problem as it is. I do not
see how this contributes anything of value outside of what array_view
provides.
On 22 Sep 2015 20:01, "'Matt Calabrese' via ISO C++ Standard - Future
Proposals" <std-proposals@isocpp.org> wrote:

> On Tue, Sep 22, 2015 at 8:27 AM, <lenkkix@gmail.com> wrote:
>>
>> Multidimensional fixed arrays (1 above) can readily be achieved today by
>> nesting std::arrays. Like so:
>>
>>     std::array<std::array<double, 4>, 3> v; // Row major 3x4 or column
>> major 4x3 depending on interpretation.
>>
>> The memory is contiguous and access is fast, sizes are fixed so the
>> compiler will generate fast code
>>
>
> Not exactly. When you make an array like that, while it is contiguous by
> some definition of contiguous, there can be padding between the rows. For
> some applications this may be fine, but if you need to interact with an API
> that requires the array to truly have all of its elements contiguous, as it
> would be with a real multidimensional array, then this is not sufficient.
> Directly and properly supporting multiple dimensions can solve this problem.
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/hW2QAvmboqU/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/.
>

--

---
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/.

--089e01227f36a25b9a05205c4c1c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Padding between rows is what stride attributes are for. Even=
 so a linear vector or array backing a array_view solves the problem as it =
is. I do not see how this contributes anything of value outside of what arr=
ay_view provides. </p>
<div class=3D"gmail_quote">On 22 Sep 2015 20:01, &quot;&#39;Matt Calabrese&=
#39; via ISO C++ Standard - Future Proposals&quot; &lt;<a href=3D"mailto:st=
d-proposals@isocpp.org">std-proposals@isocpp.org</a>&gt; wrote:<br type=3D"=
attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"=
gmail_extra"><div class=3D"gmail_quote">On Tue, Sep 22, 2015 at 8:27 AM,  <=
span dir=3D"ltr">&lt;<a href=3D"mailto:lenkkix@gmail.com" target=3D"_blank"=
>lenkkix@gmail.com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div><div>Multidimensional fixed arrays (1 above) can readily =
be achieved today by nesting std::arrays. Like so:=C2=A0</div><div><br></di=
v><div><div>=C2=A0 =C2=A0 std::array&lt;std::array&lt;double, 4&gt;, 3&gt; =
v; // Row major 3x4 or column major 4x3 depending on interpretation.</div><=
div>=C2=A0 =C2=A0=C2=A0</div></div><div>The memory is contiguous and access=
 is fast, sizes are fixed so the compiler will generate fast code</div></di=
v></div></blockquote><div><br></div><div>Not exactly. When you make an arra=
y like that, while it is contiguous by some definition of contiguous, there=
 can be padding between the rows. For some applications this may be fine, b=
ut if you need to interact with an API that requires the array to truly hav=
e all of its elements contiguous, as it would be with a real multidimension=
al array, then this is not sufficient. Directly and properly supporting mul=
tiple dimensions can solve this problem.</div></div></div></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/hW2QAvmboqU/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/hW2QAvmboqU=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></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 />

--089e01227f36a25b9a05205c4c1c--

.

--089e015370f6ca173605205ca077
Content-Type: text/plain; charset=UTF-8

On Tue, Sep 22, 2015 at 2:01 PM, Emily L <lenkkix@gmail.com> wrote:

> Padding between rows is what stride attributes are for. Even so a linear
> vector or array backing a array_view solves the problem as it is. I do not
> see how this contributes anything of value outside of what array_view
> provides.
>
Because this avoids having to keep your view and type separate, and
directly makes your array itself a Regular C++ type, just like you get for
any other std::array (I.E it's properly copyable, etc.). In other words,
saying that array_view is a solution that makes this unnecessary is as
questionable as saying that array_view makes a single-dimension std::array
unnecessary. One is, itself, a contiguous container, while the other is a
non-owning view into contiguous storage. They are distinct and both have
there separate purposes. One does not offer a superset of the functionality
of the other.

--

---
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/.

--089e015370f6ca173605205ca077
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Sep 22, 2015 at 2:01 PM, Emily L <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:lenkkix@gmail.com" target=3D"_blank">lenkkix@gmail.com</a>&gt;</span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">Padding between rows i=
s what stride attributes are for. Even so a linear vector or array backing =
a array_view solves the problem as it is. I do not see how this contributes=
 anything of value outside of what array_view provides.</p></blockquote><di=
v>Because this avoids having to keep your view and type separate, and direc=
tly makes your array itself a Regular C++ type, just like you get for any o=
ther std::array (I.E it&#39;s properly copyable, etc.). In other words, say=
ing that array_view is a solution that makes this unnecessary is as questio=
nable as saying that array_view makes a single-dimension std::array unneces=
sary. One is, itself, a contiguous container, while the other is a non-owni=
ng view into contiguous storage. They are distinct and both have there sepa=
rate purposes. One does not offer a superset of the functionality of the ot=
her.</div></div></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 />

--089e015370f6ca173605205ca077--

.

------=_Part_3633_1708608112.1442990114384
Content-Type: multipart/alternative;
 boundary="----=_Part_3634_1989079805.1442990114384"

------=_Part_3634_1989079805.1442990114384
Content-Type: text/plain; charset=UTF-8

I concur with you, Matt, but also array_view does not support fixed size
dimensions so will always come with a performance penalty compared to this
suggestion.

It seems that with today's core language std::array can't be changed to be
variadic on the dimensions as array<Ts...> can't be used for a template
template parameter with 1 parameter even if the instance being used has
exactly one. This I think is a language defect but probably it is best to
pick another name like matrix, albeit it is unfortunate that array_view
then will be non-orthogonal.

To me it is quite bizarre to define a view class without defining a base
class for it to be a view of. But unfortunately it seems that a lot of
people find that logical.


Den tisdag 22 september 2015 kl. 23:24:52 UTC+2 skrev Matt Calabrese:
>
> On Tue, Sep 22, 2015 at 2:01 PM, Emily L <len...@gmail.com <javascript:>>
> wrote:
>
>> Padding between rows is what stride attributes are for. Even so a linear
>> vector or array backing a array_view solves the problem as it is. I do not
>> see how this contributes anything of value outside of what array_view
>> provides.
>>
> Because this avoids having to keep your view and type separate, and
> directly makes your array itself a Regular C++ type, just like you get for
> any other std::array (I.E it's properly copyable, etc.). In other words,
> saying that array_view is a solution that makes this unnecessary is as
> questionable as saying that array_view makes a single-dimension std::array
> unnecessary. One is, itself, a contiguous container, while the other is a
> non-owning view into contiguous storage. They are distinct and both have
> there separate purposes. One does not offer a superset of the functionality
> of the other.
>

--

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

<div dir=3D"ltr"><div>I concur with you, Matt, but also array_view does not=
 support fixed size dimensions so will always come with a performance penal=
ty compared to this suggestion.</div><div><br></div><div>It seems that with=
 today&#39;s core language std::array can&#39;t be changed to be variadic o=
n the dimensions as array&lt;Ts...&gt; can&#39;t be used for a template tem=
plate parameter with 1 parameter even if the instance being used has exactl=
y one. This I think is a language defect but probably it is best to pick an=
other name like matrix, albeit it is unfortunate that array_view then will =
be non-orthogonal.</div><div><br></div><div>To me it is quite bizarre to de=
fine a view class without defining a base class for it to be a view of. But=
 unfortunately it seems that a lot of people find that logical.</div><div><=
div><br><br>Den tisdag 22 september 2015 kl. 23:24:52 UTC+2 skrev Matt Cala=
brese:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><d=
iv class=3D"gmail_quote">On Tue, Sep 22, 2015 at 2:01 PM, Emily L <span dir=
=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"8eEE4nklBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">len...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><p dir=3D"ltr">Padding between rows is what stride attributes are for=
.. Even so a linear vector or array backing a array_view solves the problem =
as it is. I do not see how this contributes anything of value outside of wh=
at array_view provides.</p></blockquote><div>Because this avoids having to =
keep your view and type separate, and directly makes your array itself a Re=
gular C++ type, just like you get for any other std::array (I.E it&#39;s pr=
operly copyable, etc.). In other words, saying that array_view is a solutio=
n that makes this unnecessary is as questionable as saying that array_view =
makes a single-dimension std::array unnecessary. One is, itself, a contiguo=
us container, while the other is a non-owning view into contiguous storage.=
 They are distinct and both have there separate purposes. One does not offe=
r a superset of the functionality of the other.</div></div></div></div>
</blockquote></div></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_3634_1989079805.1442990114384--
------=_Part_3633_1708608112.1442990114384--

.

--001a113e74805a4cbf0520655b84
Content-Type: text/plain; charset=UTF-8

I think that extending the array_view for fixed sizes is useful and
desirable. As pointed out this had performance benefits. However the
benefits are independent of whether or not the backing type is fixed or
dynamic. Which is a very good thing.

@Bengt they have defined a base class for it to be a view of: std::array
and std::vector which both provide suitable backing.

The most obvious uses for such a multidimensional array would be to
implement matrices, images and voxel spaces. All of which require
additional, disjunct sets of operations. So the user will need to wrap the
container anyway, using vector or array plus array_view is an
implementation detail. The benefit of implementing like this is that it
becomes easy to expose the data for interoperability in a standard and safe
way by simply returning the view, as is.

Another way of staying it is that multi_array (this proposal) can directly
be implemented by array_view and vector/array which implies that
multi_array is but a convenience. One that I do not believe adds
significant value.

(written from a phone, pardon the typos and grammatical atrocities)
On 23 Sep 2015 08:35, "Bengt Gustafsson" <bengt.gustafsson@beamways.com>
wrote:

> I concur with you, Matt, but also array_view does not support fixed size
> dimensions so will always come with a performance penalty compared to this
> suggestion.
>
> It seems that with today's core language std::array can't be changed to be
> variadic on the dimensions as array<Ts...> can't be used for a template
> template parameter with 1 parameter even if the instance being used has
> exactly one. This I think is a language defect but probably it is best to
> pick another name like matrix, albeit it is unfortunate that array_view
> then will be non-orthogonal.
>
> To me it is quite bizarre to define a view class without defining a base
> class for it to be a view of. But unfortunately it seems that a lot of
> people find that logical.
>
>
> Den tisdag 22 september 2015 kl. 23:24:52 UTC+2 skrev Matt Calabrese:
>>
>> On Tue, Sep 22, 2015 at 2:01 PM, Emily L <len...@gmail.com> wrote:
>>
>>> Padding between rows is what stride attributes are for. Even so a linear
>>> vector or array backing a array_view solves the problem as it is. I do not
>>> see how this contributes anything of value outside of what array_view
>>> provides.
>>>
>> Because this avoids having to keep your view and type separate, and
>> directly makes your array itself a Regular C++ type, just like you get for
>> any other std::array (I.E it's properly copyable, etc.). In other words,
>> saying that array_view is a solution that makes this unnecessary is as
>> questionable as saying that array_view makes a single-dimension std::array
>> unnecessary. One is, itself, a contiguous container, while the other is a
>> non-owning view into contiguous storage. They are distinct and both have
>> there separate purposes. One does not offer a superset of the functionality
>> of the other.
>>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/hW2QAvmboqU/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/.
>

--

---
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/.

--001a113e74805a4cbf0520655b84
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">I think that extending the array_view for fixed sizes is use=
ful and desirable. As pointed out this had performance benefits. However th=
e benefits are independent of whether or not the backing type is fixed or d=
ynamic. Which is a very good thing.</p>
<p dir=3D"ltr">@Bengt they have defined a base class for it to be a view of=
: std::array and std::vector which both provide suitable backing.</p>
<p dir=3D"ltr">The most obvious uses for such a multidimensional array woul=
d be to implement matrices, images and voxel spaces. All of which require a=
dditional, disjunct sets of operations. So the user will need to wrap the c=
ontainer anyway, using vector or array plus array_view is an implementation=
 detail. The benefit of implementing like this is that it becomes easy to e=
xpose the data for interoperability in a standard and safe way by simply re=
turning the view, as is. </p>
<p dir=3D"ltr">Another way of staying it is that multi_array (this proposal=
) can directly be implemented by array_view and vector/array which implies =
that multi_array is but a convenience. One that I do not believe adds signi=
ficant value. </p>
<p dir=3D"ltr">(written from a phone, pardon the typos and grammatical atro=
cities) </p>
<div class=3D"gmail_quote">On 23 Sep 2015 08:35, &quot;Bengt Gustafsson&quo=
t; &lt;<a href=3D"mailto:bengt.gustafsson@beamways.com">bengt.gustafsson@be=
amways.com</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div>I concur with you, Matt, but also array_view do=
es not support fixed size dimensions so will always come with a performance=
 penalty compared to this suggestion.</div><div><br></div><div>It seems tha=
t with today&#39;s core language std::array can&#39;t be changed to be vari=
adic on the dimensions as array&lt;Ts...&gt; can&#39;t be used for a templa=
te template parameter with 1 parameter even if the instance being used has =
exactly one. This I think is a language defect but probably it is best to p=
ick another name like matrix, albeit it is unfortunate that array_view then=
 will be non-orthogonal.</div><div><br></div><div>To me it is quite bizarre=
 to define a view class without defining a base class for it to be a view o=
f. But unfortunately it seems that a lot of people find that logical.</div>=
<div><div><br><br>Den tisdag 22 september 2015 kl. 23:24:52 UTC+2 skrev Mat=
t Calabrese:<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 class=3D"gmail_quote">On Tue, Sep 22, 2015 at 2:01 PM, Emily L <span di=
r=3D"ltr">&lt;<a rel=3D"nofollow">len...@gmail.com</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><p dir=3D"ltr">Padding between rows is what=
 stride attributes are for. Even so a linear vector or array backing a arra=
y_view solves the problem as it is. I do not see how this contributes anyth=
ing of value outside of what array_view provides.</p></blockquote><div>Beca=
use this avoids having to keep your view and type separate, and directly ma=
kes your array itself a Regular C++ type, just like you get for any other s=
td::array (I.E it&#39;s properly copyable, etc.). In other words, saying th=
at array_view is a solution that makes this unnecessary is as questionable =
as saying that array_view makes a single-dimension std::array unnecessary. =
One is, itself, a contiguous container, while the other is a non-owning vie=
w into contiguous storage. They are distinct and both have there separate p=
urposes. One does not offer a superset of the functionality of the other.</=
div></div></div></div>
</blockquote></div></div></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/hW2QAvmboqU/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/hW2QAvmboqU=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></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 />

--001a113e74805a4cbf0520655b84--

.

------=_Part_70_517150582.1443037778247
Content-Type: multipart/alternative;
 boundary="----=_Part_71_1768487136.1443037778248"

------=_Part_71_1768487136.1443037778248
Content-Type: text/plain; charset=UTF-8



Den onsdag 23 september 2015 kl. 09:49:41 UTC+2 skrev Emily L:
>
> I think that extending the array_view for fixed sizes is useful and
> desirable. As pointed out this had performance benefits. However the
> benefits are independent of whether or not the backing type is fixed or
> dynamic. Which is a very good thing.
>
Well, there is a difference between a fixed size array_view and an
array_view on a fixed size backing. When providing only fixed size you
still have a runtime stored stride whether you need it or not. But maybe
this can be attained too, if section() is defined to return different view
types depending on the "parent" view type. This gets fairly complicated
though. The code needed is basically available in my original prototype of
the matrix template.

@Bengt they have defined a base class for it to be a view of: std::array
> and std::vector which both provide suitable backing.
>
I assume you mean constructors. At least that is what I found in
the http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4177.html
proposal. Or is there newer version?



> The most obvious uses for such a multidimensional array would be to
> implement matrices, images and voxel spaces. All of which require
> additional, disjunct sets of operations. So the user will need to wrap the
> container anyway, using vector or array plus array_view is an
> implementation detail. The benefit of implementing like this is that it
> becomes easy to expose the data for interoperability in a standard and safe
> way by simply returning the view, as is.
>
> Another way of staying it is that multi_array (this proposal) can directly
> be implemented by array_view and vector/array which implies that
> multi_array is but a convenience. One that I do not believe adds
> significant value.
>

This way of thinking leads into the same trap that plagues other parts of
the C++ library (although it gets better): By not providing good and
complete vocabulary types each library developer has to reinvent the wheel
again. Granted, the array_view helps a bit with interoperability but
obvsously programmers will expect an easy to use matrix class without
having to bend over backwards. What is the harm in providing a complete
library?


> (written from a phone, pardon the typos and grammatical atrocities)
> On 23 Sep 2015 08:35, "Bengt Gustafsson" <bengt.gu...@beamways.com
> <javascript:>> wrote:
>
>> I concur with you, Matt, but also array_view does not support fixed size
>> dimensions so will always come with a performance penalty compared to this
>> suggestion.
>>
>> It seems that with today's core language std::array can't be changed to
>> be variadic on the dimensions as array<Ts...> can't be used for a template
>> template parameter with 1 parameter even if the instance being used has
>> exactly one. This I think is a language defect but probably it is best to
>> pick another name like matrix, albeit it is unfortunate that array_view
>> then will be non-orthogonal.
>>
>> To me it is quite bizarre to define a view class without defining a base
>> class for it to be a view of. But unfortunately it seems that a lot of
>> people find that logical.
>>
>>
>> Den tisdag 22 september 2015 kl. 23:24:52 UTC+2 skrev Matt Calabrese:
>>>
>>> On Tue, Sep 22, 2015 at 2:01 PM, Emily L <len...@gmail.com> wrote:
>>>
>>>> Padding between rows is what stride attributes are for. Even so a
>>>> linear vector or array backing a array_view solves the problem as it is. I
>>>> do not see how this contributes anything of value outside of what
>>>> array_view provides.
>>>>
>>> Because this avoids having to keep your view and type separate, and
>>> directly makes your array itself a Regular C++ type, just like you get for
>>> any other std::array (I.E it's properly copyable, etc.). In other words,
>>> saying that array_view is a solution that makes this unnecessary is as
>>> questionable as saying that array_view makes a single-dimension std::array
>>> unnecessary. One is, itself, a contiguous container, while the other is a
>>> non-owning view into contiguous storage. They are distinct and both have
>>> there separate purposes. One does not offer a superset of the functionality
>>> of the other.
>>>
>> --
>>
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/hW2QAvmboqU/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>

--

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

<div dir=3D"ltr"><br><br>Den onsdag 23 september 2015 kl. 09:49:41 UTC+2 sk=
rev Emily L:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr">I t=
hink that extending the array_view for fixed sizes is useful and desirable.=
 As pointed out this had performance benefits. However the benefits are ind=
ependent of whether or not the backing type is fixed or dynamic. Which is a=
 very good thing.</p></blockquote><div>Well, there is a difference between =
a fixed size array_view and an array_view on a fixed size backing. When pro=
viding only fixed size you still have a runtime stored stride whether you n=
eed it or not. But maybe this can be attained too, if section() is defined =
to return different view types depending on the &quot;parent&quot; view typ=
e. This gets fairly complicated though. The code needed is basically availa=
ble in my original prototype of the matrix template.</div><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">
<p dir=3D"ltr">@Bengt they have defined a base class for it to be a view of=
: std::array and std::vector which both provide suitable backing.</p></bloc=
kquote><div>I assume you mean constructors. At least that is what I found i=
n the=C2=A0http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4177.ht=
ml proposal. Or is there newer version?</div><div><br></div><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">
<p dir=3D"ltr">The most obvious uses for such a multidimensional array woul=
d be to implement matrices, images and voxel spaces. All of which require a=
dditional, disjunct sets of operations. So the user will need to wrap the c=
ontainer anyway, using vector or array plus array_view is an implementation=
 detail. The benefit of implementing like this is that it becomes easy to e=
xpose the data for interoperability in a standard and safe way by simply re=
turning the view, as is. </p>
<p dir=3D"ltr">Another way of staying it is that multi_array (this proposal=
) can directly be implemented by array_view and vector/array which implies =
that multi_array is but a convenience. One that I do not believe adds signi=
ficant value.</p></blockquote><div>=C2=A0</div><div>This way of thinking le=
ads into the same trap that plagues other parts of the C++ library (althoug=
h it gets better): By not providing good and complete vocabulary types each=
 library developer has to reinvent the wheel again. Granted, the array_view=
 helps a bit with interoperability but obvsously programmers will expect an=
 easy to use matrix class without having to bend over backwards. What is th=
e harm in providing a complete library?</div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;"><p dir=3D"ltr"> </p>
<p dir=3D"ltr">(written from a phone, pardon the typos and grammatical atro=
cities) </p>
<div class=3D"gmail_quote">On 23 Sep 2015 08:35, &quot;Bengt Gustafsson&quo=
t; &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"8=
kN7o5JHBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#=
39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;=
">bengt.gu...@beamways.com</a><wbr>&gt; wrote:<br type=3D"attribution"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div>I concur with you, Matt, b=
ut also array_view does not support fixed size dimensions so will always co=
me with a performance penalty compared to this suggestion.</div><div><br></=
div><div>It seems that with today&#39;s core language std::array can&#39;t =
be changed to be variadic on the dimensions as array&lt;Ts...&gt; can&#39;t=
 be used for a template template parameter with 1 parameter even if the ins=
tance being used has exactly one. This I think is a language defect but pro=
bably it is best to pick another name like matrix, albeit it is unfortunate=
 that array_view then will be non-orthogonal.</div><div><br></div><div>To m=
e it is quite bizarre to define a view class without defining a base class =
for it to be a view of. But unfortunately it seems that a lot of people fin=
d that logical.</div><div><div><br><br>Den tisdag 22 september 2015 kl. 23:=
24:52 UTC+2 skrev Matt Calabrese:<blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div><div class=3D"gmail_quote">On Tue, Sep 22, 2015 at 2:01=
 PM, Emily L <span dir=3D"ltr">&lt;<a rel=3D"nofollow">len...@gmail.com</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">Padding=
 between rows is what stride attributes are for. Even so a linear vector or=
 array backing a array_view solves the problem as it is. I do not see how t=
his contributes anything of value outside of what array_view provides.</p><=
/blockquote><div>Because this avoids having to keep your view and type sepa=
rate, and directly makes your array itself a Regular C++ type, just like yo=
u get for any other std::array (I.E it&#39;s properly copyable, etc.). In o=
ther words, saying that array_view is a solution that makes this unnecessar=
y is as questionable as saying that array_view makes a single-dimension std=
::array unnecessary. One is, itself, a contiguous container, while the othe=
r is a non-owning view into contiguous storage. They are distinct and both =
have there separate purposes. One does not offer a superset of the function=
ality of the other.</div></div></div></div>
</blockquote></div></div></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/hW2QAvmboqU/unsubscribe" target=3D"_blan=
k" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.c=
om/a/isocpp.org/d/topic/std-proposals/hW2QAvmboqU/unsubscribe&#39;;return t=
rue;" onclick=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/=
topic/std-proposals/hW2QAvmboqU/unsubscribe&#39;;return true;">https://grou=
ps.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/hW2QAvmboqU/<wbr=
>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"8kN7o5JHBgAJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">std-proposal=
....@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"8kN7o5JHBgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.or=
g/group/std-proposals/&#39;;return true;">http://groups.google.com/a/<wbr>i=
socpp.org/group/std-<wbr>proposals/</a>.<br>
</blockquote></div>
</blockquote></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_71_1768487136.1443037778248--
------=_Part_70_517150582.1443037778247--

.