------=_Part_454_132762098.1429137721413
Content-Type: multipart/alternative;
 boundary="----=_Part_455_97071853.1429137721413"

------=_Part_455_97071853.1429137721413
Content-Type: text/plain; charset=UTF-8

Hello.

I think that the subject has already been discussed here, but I would like
a clarification about N4346
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4346.html>.
What does the multidimensional bounds proposal (I'm not a specialist of it,
I've just read it quickly) does not allow a template parameter to specify
the ordering?
I mean is there a particular reason, technical or in terms of software
design?

Thank you.
Vincent

--

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

<div dir=3D"ltr">Hello.<br><br>I think that the subject has already been di=
scussed here, but I would like a clarification about <a href=3D"http://www.=
open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4346.html">N4346</a>.<br>What=
 does the multidimensional bounds proposal (I'm not a specialist of it, I'v=
e just read it quickly) does not allow a template parameter to specify the =
ordering?<br>I mean is there a particular reason, technical or in terms of =
software design?<br><br>Thank you.<br>Vincent<br></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_455_97071853.1429137721413--
------=_Part_454_132762098.1429137721413--

.

------=_Part_8187_1680039163.1429201741791
Content-Type: multipart/alternative;
 boundary="----=_Part_8188_1303221785.1429201741792"

------=_Part_8188_1303221785.1429201741792
Content-Type: text/plain; charset=UTF-8


On Wednesday, April 15, 2015 at 3:42:01 PM UTC-7, Vincent Reverdy wrote:
>
> I think that the subject has already been discussed here, but I would like
> a clarification about N4346
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4346.html>.
> What does the multidimensional bounds proposal (I'm not a specialist of
> it, I've just read it quickly) does not allow a template parameter to
> specify the ordering?
> I mean is there a particular reason, technical or in terms of software
> design?
>

The design is a straightforward template parameter.  There are some
complexities in implementation, but it is something that nearly every
alternative 2+ dimensional library has done.  There are also many
unresolved performance concerns about the reliance on operator[], and the
lack of ordering not enabling cache locality or efficient algorithms with
large arrays.  These issues were the reason that
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4222.pdf  was
written (and N4300, though I never found it online).

An alternative approach, which resolves all of these issues as far as I can
tell, is given in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4355.pdf written
by Carter and Trott at Sandia.   These guys are the experts,
and supersede anything I might say, but my feeling is that the N4355
alternative proposed is significantly better than the N4346 approach.  Not
only does it capture the spirit of what this is (wrapping a pointer to an
underlying data source and collecting all possible static/dynamic details
on layouts and extents), but it can be implemented with zero overhead from
abstractions and with all possible optimizations for downstream users of
the library (since it doesn't throw away static layout/ordering
information).  It doesn't have the slices and subarray features yet, but
that can be added later without any issues as they show.

--

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

<div dir=3D"ltr"><br>On Wednesday, April 15, 2015 at 3:42:01 PM UTC-7, Vinc=
ent Reverdy wrote:<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">I think that the subject has already been discussed here, but I would =
like a clarification about <a href=3D"http://www.open-std.org/jtc1/sc22/wg2=
1/docs/papers/2015/n4346.html" target=3D"_blank" rel=3D"nofollow" onmousedo=
wn=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.=
org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fn4346.html\46sa\75D\46snt=
z\0751\46usg\75AFQjCNHI_iEbVS6SSr3TLUAXlOwlwoxqOA';return true;" onclick=3D=
"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2=
Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fn4346.html\46sa\75D\46sntz\075=
1\46usg\75AFQjCNHI_iEbVS6SSr3TLUAXlOwlwoxqOA';return true;">N4346</a>.<br>W=
hat does the multidimensional bounds proposal (I'm not a specialist of it, =
I've just read it quickly) does not allow a template parameter to specify t=
he ordering?<br>I mean is there a particular reason, technical or in terms =
of software design?<br></div></blockquote><div><br></div><div><span>The des=
ign is a straightforward template parameter. &nbsp;There are some complexit=
ies in implementation, but it is something that nearly every alternative 2+=
 dimensional library has done. &nbsp;There are also many unresolved perform=
ance concerns about the reliance on operator[], and the lack of ordering no=
t enabling cache locality or efficient algorithms with large arrays. &nbsp;=
These issues were the reason that <a class=3D"linkclass" href=3D"http://www=
..open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4222.pdf">http://www.open-st=
d.org/jtc1/sc22/wg21/docs/papers/2014/n4222.pdf</a>&nbsp;</span>&nbsp;was w=
ritten (and N4300, though I never found it online).</div><div><span><br></s=
pan></div><div><span>An alternative approach, which resolves all of these i=
ssues as far as I can tell, is given in&nbsp;<a class=3D"linkclass" href=3D=
"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4355.pdf">http://=
www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4355.pdf</a>&nbsp;written=
 by Carter and Trott at Sandia. &nbsp; These guys are the experts, and&nbsp=
;supersede&nbsp;anything I might say, but m</span>y feeling is that the N43=
55 alternative proposed is significantly better than the N4346 approach. &n=
bsp;Not only does it capture the spirit of what this is (wrapping a pointer=
 to an underlying data source and collecting all possible static/dynamic de=
tails on layouts and extents), but it can be implemented with zero overhead=
 from abstractions and with all possible optimizations for downstream users=
 of the library (since it doesn't throw away static layout/ordering informa=
tion). &nbsp;It doesn't have the slices and subarray features yet, but that=
 can be added later without any issues as they show.</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_8188_1303221785.1429201741792--
------=_Part_8187_1680039163.1429201741791--

.

------=_Part_154_279507018.1429237793037
Content-Type: multipart/alternative;
 boundary="----=_Part_155_1127715537.1429237793037"

------=_Part_155_1127715537.1429237793037
Content-Type: text/plain; charset=UTF-8

On Thursday, April 16, 2015 at 6:29:01 PM UTC+2, Jesse Perla wrote:
>
>
> On Wednesday, April 15, 2015 at 3:42:01 PM UTC-7, Vincent Reverdy wrote:
>>
>> I think that the subject has already been discussed here, but I would
>> like a clarification about N4346
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4346.html>.
>> What does the multidimensional bounds proposal (I'm not a specialist of
>> it, I've just read it quickly) does not allow a template parameter to
>> specify the ordering?
>> I mean is there a particular reason, technical or in terms of software
>> design?
>>
>
> The design is a straightforward template parameter.  There are some
> complexities in implementation, but it is something that nearly every
> alternative 2+ dimensional library has done.  There are also many
> unresolved performance concerns about the reliance on operator[], and the
> lack of ordering not enabling cache locality or efficient algorithms with
> large arrays.  These issues were the reason that
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4222.pdf  was
> written (and N4300, though I never found it online).
>
> An alternative approach, which resolves all of these issues as far as I
> can tell, is given in
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4355.pdf written
> by Carter and Trott at Sandia.   These guys are the experts,
> and supersede anything I might say, but my feeling is that the N4355
> alternative proposed is significantly better than the N4346 approach.  Not
> only does it capture the spirit of what this is (wrapping a pointer to an
> underlying data source and collecting all possible static/dynamic details
> on layouts and extents), but it can be implemented with zero overhead from
> abstractions and with all possible optimizations for downstream users of
> the library (since it doesn't throw away static layout/ordering
> information).  It doesn't have the slices and subarray features yet, but
> that can be added later without any issues as they show.
>

 I very much support the general direction of n4355 as an alternative to
n4346, which I agree is much too limited.  There is also a critical point
to key in mind with regard to standardizing any array_view library: it is,
in general, possible to convert between different multi-dimensional array
types, with practically no overhead (i.e. no copying of the actual data),
provided that they are designed to be sufficiently general.  It is,
therefore, not terribly important whether two pieces of code that deal with
multi-dimensional arrays, and which the use would like to use together,
actually use the same types to represent these arrays.  This is quite a
different situation from types like vector or string (assuming that
string_view or a single-dimensional array_view would not be suitable due to
the need to change the size) where there is a large advantage in
standardizing on a single type.  We can and should, therefore, be
especially cautious in standardizing a multi-dimensional array facility.
Standardization is supposed to be about standardizing existing practice: it
is plainly obvious to me that there simply isn't any well-established
existing practice yet.

I would love to see more development of C++ libraries for multi-dimensional
arrays, but I don't see any reason to involve the standardization committee
at this stage.  When there is a library that has become for C++ what numpy
is for Python, then we should consider standardizing.

--

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

<div dir=3D"ltr">On Thursday, April 16, 2015 at 6:29:01 PM UTC+2, Jesse Per=
la 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"><br>=
On Wednesday, April 15, 2015 at 3:42:01 PM UTC-7, Vincent Reverdy wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I think that the subj=
ect has already been discussed here, but I would like a clarification about=
 <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4346.h=
tml" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'http://=
www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2=
Fdocs%2Fpapers%2F2015%2Fn4346.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHI_iE=
bVS6SSr3TLUAXlOwlwoxqOA';return true;" onclick=3D"this.href=3D'http://www.g=
oogle.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs=
%2Fpapers%2F2015%2Fn4346.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHI_iEbVS6S=
Sr3TLUAXlOwlwoxqOA';return true;">N4346</a>.<br>What does the multidimensio=
nal bounds proposal (I'm not a specialist of it, I've just read it quickly)=
 does not allow a template parameter to specify the ordering?<br>I mean is =
there a particular reason, technical or in terms of software design?<br></d=
iv></blockquote><div><br></div><div><span>The design is a straightforward t=
emplate parameter. &nbsp;There are some complexities in implementation, but=
 it is something that nearly every alternative 2+ dimensional library has d=
one. &nbsp;There are also many unresolved performance concerns about the re=
liance on operator[], and the lack of ordering not enabling cache locality =
or efficient algorithms with large arrays. &nbsp;These issues were the reas=
on that <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/=
n4222.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'h=
ttp://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2F=
wg21%2Fdocs%2Fpapers%2F2014%2Fn4222.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCN=
EuX3eoDV_El5RHR33lxPeOi5cKwg';return true;" onclick=3D"this.href=3D'http://=
www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2=
Fdocs%2Fpapers%2F2014%2Fn4222.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNEuX3eo=
DV_El5RHR33lxPeOi5cKwg';return true;">http://www.open-std.org/jtc1/<wbr>sc2=
2/wg21/docs/papers/2014/<wbr>n4222.pdf</a>&nbsp;</span>&nbsp;was written (a=
nd N4300, though I never found it online).</div><div><span><br></span></div=
><div><span>An alternative approach, which resolves all of these issues as =
far as I can tell, is given in&nbsp;<a href=3D"http://www.open-std.org/jtc1=
/sc22/wg21/docs/papers/2015/n4355.pdf" target=3D"_blank" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.o=
pen-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fn4355.pdf\46sa\75=
D\46sntz\0751\46usg\75AFQjCNH2wQRcBnU_A0sJPzr3dmzrdC1Qow';return true;" onc=
lick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-st=
d.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fn4355.pdf\46sa\75D\46sn=
tz\0751\46usg\75AFQjCNH2wQRcBnU_A0sJPzr3dmzrdC1Qow';return true;">http://ww=
w.open-std.org/<wbr>jtc1/sc22/wg21/docs/papers/<wbr>2015/n4355.pdf</a>&nbsp=
;written by Carter and Trott at Sandia. &nbsp; These guys are the experts, =
and&nbsp;supersede&nbsp;anything I might say, but m</span>y feeling is that=
 the N4355 alternative proposed is significantly better than the N4346 appr=
oach. &nbsp;Not only does it capture the spirit of what this is (wrapping a=
 pointer to an underlying data source and collecting all possible static/dy=
namic details on layouts and extents), but it can be implemented with zero =
overhead from abstractions and with all possible optimizations for downstre=
am users of the library (since it doesn't throw away static layout/ordering=
 information). &nbsp;It doesn't have the slices and subarray features yet, =
but that can be added later without any issues as they show.</div></div></b=
lockquote><div><br>&nbsp;I very much support the general direction of n4355=
 as an alternative to n4346, which I agree is much too limited.&nbsp; There=
 is also a critical point to key in mind with regard to standardizing any a=
rray_view library: it is, in general, possible to convert between different=
 multi-dimensional array types, with practically no overhead (i.e. no copyi=
ng of the actual data), provided that they are designed to be sufficiently =
general.&nbsp; It is, therefore, not terribly important whether two pieces =
of code that deal with multi-dimensional arrays, and which the use would li=
ke to use together, actually use the same types to represent these arrays.&=
nbsp; This is quite a different situation from types like vector or string =
(assuming that string_view or a single-dimensional array_view would not be =
suitable due to the need to change the size) where there is a large advanta=
ge in standardizing on a single type.&nbsp; We can and should, therefore, b=
e especially cautious in standardizing a multi-dimensional array facility.&=
nbsp; Standardization is supposed to be about standardizing existing practi=
ce: it is plainly obvious to me that there simply isn't any well-establishe=
d existing practice yet.<br><br>I would love to see more development of C++=
 libraries for multi-dimensional arrays, but I don't see any reason to invo=
lve the standardization committee at this stage.&nbsp; When there is a libr=
ary that has become for C++ what numpy is for Python, then we should consid=
er standardizing.<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_155_1127715537.1429237793037--
------=_Part_154_279507018.1429237793037--

.

------=_Part_107_1724836797.1429740617505
Content-Type: multipart/alternative;
 boundary="----=_Part_108_450296326.1429740617505"

------=_Part_108_450296326.1429740617505
Content-Type: text/plain; charset=UTF-8


On Thursday, April 16, 2015 at 7:29:53 PM UTC-7, Jeremy Maitin-Shepard
wrote:
>
>  I very much support the general direction of n4355 as an alternative to
> n4346, which I agree is much too limited.  There is also a critical point
> to key in mind with regard to standardizing any array_view library: it is,
> in general, possible to convert between different multi-dimensional array
> types, with practically no overhead (i.e. no copying of the actual data),
> provided that they are designed to be sufficiently general.  It is,
> therefore, not terribly important whether two pieces of code that deal with
> multi-dimensional arrays, and which the use would like to use together,
> actually use the same types to represent these arrays.  This is quite a
> different situation from types like vector or string (assuming that
> string_view or a single-dimensional array_view would not be suitable due to
> the need to change the size) where there is a large advantage in
> standardizing on a single type.  We can and should, therefore, be
> especially cautious in standardizing a multi-dimensional array facility.
> Standardization is supposed to be about standardizing existing practice: it
> is plainly obvious to me that there simply isn't any well-established
> existing practice yet.
>

Both proposals are carefully avoiding standardizing an actual
multi-dimensional array container, which I think is in line with your
instinct.  The key then is whether the class captures all of the static and
dynamic information necessary for conversion between different libraries so
you can pass it around.  If it doesn't, then you are no better off than
passing around the raw pointer.  N4355 contains the static/layout info.
 N3456 does not.  To me, this is much more important than adding in
slices/etc.


But the bigger question is: why isn't there any existing practice to
standardize if this has been around for decades and is such a pain point?
 Sadly, the array view class it is of limited use on its own, and the gains
come from libraries start to accept it for interoperability.  So until it
exists, there is no reason to work on it or support it.  It is a
coordination problem, and the standard committee may be the only ones who
can solve it.


>
> I would love to see more development of C++ libraries for
> multi-dimensional arrays, but I don't see any reason to involve the
> standardization committee at this stage.  When there is a library that has
> become for C++ what numpy is for Python, then we should consider
> standardizing.
>

Python != C++ due to the diversity of opportunities for optimization and
embedded domain specific languages.  If there was going to be a single
multi-array container or matrix library to bind them all, there would be a
contender  at this point.  Because of expression templates, etc. there may
never be one.  So you are left with everyone creating their own, which is a
complete mess and getting worse.  These proposals are intended to have a
standard view to pass around between libraries so that each library with
their own preferred internal library.


--

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

<div dir=3D"ltr"><br>On Thursday, April 16, 2015 at 7:29:53 PM UTC-7, Jerem=
y Maitin-Shepard wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><div>&nbsp;I very much support the general direction of n4355 as =
an alternative to n4346, which I agree is much too limited.&nbsp; There is =
also a critical point to key in mind with regard to standardizing any array=
_view library: it is, in general, possible to convert between different mul=
ti-dimensional array types, with practically no overhead (i.e. no copying o=
f the actual data), provided that they are designed to be sufficiently gene=
ral.&nbsp; It is, therefore, not terribly important whether two pieces of c=
ode that deal with multi-dimensional arrays, and which the use would like t=
o use together, actually use the same types to represent these arrays.&nbsp=
; This is quite a different situation from types like vector or string (ass=
uming that string_view or a single-dimensional array_view would not be suit=
able due to the need to change the size) where there is a large advantage i=
n standardizing on a single type.&nbsp; We can and should, therefore, be es=
pecially cautious in standardizing a multi-dimensional array facility.&nbsp=
; Standardization is supposed to be about standardizing existing practice: =
it is plainly obvious to me that there simply isn't any well-established ex=
isting practice yet.<br></div></div></blockquote><div><br></div><div><div>B=
oth proposals are carefully avoiding standardizing an actual multi-dimensio=
nal array container, which I think is in line with your instinct. &nbsp;The=
 key then is whether the class captures all of the static and dynamic infor=
mation necessary for conversion between different libraries so you can pass=
 it around. &nbsp;If it doesn't, then you are no better off than passing ar=
ound the raw pointer. &nbsp;N4355 contains the static/layout info. &nbsp;N3=
456 does not. &nbsp;To me, this is much more important than adding in slice=
s/etc.</div><div><br></div><div><br></div><div>But the bigger question is: =
why isn't there any existing practice to standardize if this has been aroun=
d for decades and is such a pain point? &nbsp;Sadly, the array view class i=
t is of limited use on its own, and the gains come from libraries start to =
accept it for interoperability. &nbsp;So until it exists, there is no reaso=
n to work on it or support it. &nbsp;It is a coordination problem, and the =
standard committee may be the only ones who can solve it.</div></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"><d=
iv><br>I would love to see more development of C++ libraries for multi-dime=
nsional arrays, but I don't see any reason to involve the standardization c=
ommittee at this stage.&nbsp; When there is a library that has become for C=
++ what numpy is for Python, then we should consider standardizing.<br></di=
v></div></blockquote><div><br></div><div>Python !=3D C++ due to the diversi=
ty of opportunities for optimization and embedded domain specific languages=
.. &nbsp;If there was going to be a single multi-array container or matrix l=
ibrary to bind them all, there would be a contender &nbsp;at this point. &n=
bsp;Because of expression templates, etc. there may never be one. &nbsp;So =
you are left with everyone creating their own, which is a complete mess and=
 getting worse. &nbsp;These proposals are intended to have a standard view =
to pass around between libraries so that each library with their own prefer=
red internal library.<br></div><div>&nbsp;</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_108_450296326.1429740617505--
------=_Part_107_1724836797.1429740617505--

.

------=_Part_81_674737407.1441241749727
Content-Type: multipart/alternative;
 boundary="----=_Part_82_1565022024.1441241749728"

------=_Part_82_1565022024.1441241749728
Content-Type: text/plain; charset=UTF-8

I think that while array_view could theoretically provide a template
parameter for the ordering but strided_array_view not, as a consequence of
the general design of the classes:

- strided_array_view provides row-major/column-major compatibility by
allowing arbitrary stride values for each dimensions. A strided_array_view
with a 'column-major'-tag  could still have row-major ordering with the
appropriate run-time stride values.
- strided_array_view needs to have arbitrary stride values in order to
provide sub-array views with minimal overhead. The extra overhead would be
the pointer to the original array + offsets.

If one really needs to have a static guarantee about the ordering than
N4355 is the way to go, which proposes 3 orderings: row-major, column-major
and a similar arbitrary-strided one. The price to pay is the simplicity of
the original C pattern ( e.g. void inverse(double*M, int w, int h) ).

On Thursday, April 16, 2015 at 12:42:01 AM UTC+2, Vincent Reverdy wrote:
>
> Hello.
>
> I think that the subject has already been discussed here, but I would like
> a clarification about N4346
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4346.html>.
> What does the multidimensional bounds proposal (I'm not a specialist of
> it, I've just read it quickly) does not allow a template parameter to
> specify the ordering?
> I mean is there a particular reason, technical or in terms of software
> design?
>
> Thank you.
> Vincent
>

--

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

<div dir=3D"ltr">I think that while array_view could theoretically provide =
a template parameter for the ordering but strided_array_view not, as a cons=
equence of the general design of the classes:<div><br></div><div>- strided_=
array_view provides row-major/column-major compatibility by allowing arbitr=
ary stride values for each dimensions. A strided_array_view with a &#39;col=
umn-major&#39;-tag =C2=A0could still have row-major ordering with the appro=
priate run-time stride values.</div><div>- strided_array_view needs to have=
 arbitrary stride values in order to provide sub-array views with minimal o=
verhead. The extra overhead would be the pointer to the original array + of=
fsets.</div><div><br></div><div>If one really needs to have a static guaran=
tee about the ordering than N4355 is the way to go, which proposes 3 orderi=
ngs: row-major, column-major and a similar arbitrary-strided one. The price=
 to pay is the simplicity of the original C pattern ( e.g. void inverse(dou=
ble*M, int w, int h) ).</div><div><br></div><div><div>On Thursday, April 16=
, 2015 at 12:42:01 AM UTC+2, Vincent Reverdy wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr">Hello.<br><br>I think that the subjec=
t has already been discussed here, but I would like a clarification about <=
a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4346.htm=
l" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http:=
//www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21=
%2Fdocs%2Fpapers%2F2015%2Fn4346.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHI_=
iEbVS6SSr3TLUAXlOwlwoxqOA&#39;;return true;" onclick=3D"this.href=3D&#39;ht=
tp://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fw=
g21%2Fdocs%2Fpapers%2F2015%2Fn4346.html\46sa\75D\46sntz\0751\46usg\75AFQjCN=
HI_iEbVS6SSr3TLUAXlOwlwoxqOA&#39;;return true;">N4346</a>.<br>What does the=
 multidimensional bounds proposal (I&#39;m not a specialist of it, I&#39;ve=
 just read it quickly) does not allow a template parameter to specify the o=
rdering?<br>I mean is there a particular reason, technical or in terms of s=
oftware design?<br><br>Thank you.<br>Vincent<br></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_82_1565022024.1441241749728--
------=_Part_81_674737407.1441241749727--

.