Topic: Multi-dimensional array, part 2
Author: Daryle Walker <darylew@gmail.com>
Date: Fri, 4 Oct 2013 12:49:43 -0700 (PDT)
Raw View
------=_Part_549_5152844.1380916183908
Content-Type: text/plain; charset=ISO-8859-1
I figured out how to activate the web page feature of the GitHub repository
for my array proposal. It is at
http://ctmacuser.github.io/multiarray-iso-proposal. It should lead to the copy
of the proposal<http://ctmacuser.github.io/multiarray-iso-proposal/array-proposal.html> copied
there from the regular branch.
The next submission deadline is in a week, so I need a final check over.
Are there any mistakes or omissions? Is anything unclear?
Daryle W.
--
---
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_549_5152844.1380916183908
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I figured out how to activate the web page feature of=
the GitHub repository for my array proposal. It is at <a href=3D"htt=
p://ctmacuser.github.io/multiarray-iso-proposal">http://ctmacuser.github.io=
/multiarray-iso-proposal</a>. It should lead to the <a href=3D"h=
ttp://ctmacuser.github.io/multiarray-iso-proposal/array-proposal.html">copy=
of the proposal</a> copied there from the regular branch.</div><div>&=
nbsp;</div><div>The next submission deadline is in a week, so I need a fina=
l check over. Are there any mistakes or omissions? Is anything =
unclear?</div><div> </div><div>Daryle W.</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_549_5152844.1380916183908--
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Fri, 04 Oct 2013 22:32:30 +0200
Raw View
On Fri, 2013-10-04 at 12:49 -0700, Daryle Walker wrote:
> I figured out how to activate the web page feature of the GitHub
> repository for my array proposal. It is at
> http://ctmacuser.github.io/multiarray-iso-proposal. It should lead to
> the copy of the proposal copied there from the regular branch.
>
> The next submission deadline is in a week, so I need a final check
> over. Are there any mistakes or omissions? Is anything unclear?
I think you need to put a lot more effort into the motivation section.
Explain why this is something that is needed.
In "Design Decisions" you are waving your hands trying to claim that
operator[]() calls are inherently slower than calls to the built in
operator[].
Do you have any data to support this claim?
Preferably data that support that it is infeasible to achieve the same
performance.
This is important as you are disabling user defined indexing for data
stored in your class based on this.
I am strongly opposed to misappropriating the function call operator for
indexing.
std::array<int, 17> anArray;
std::function<int(int)> fun(anArray);
One can have lots of fun with that function call operator.
/MF
--
---
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/.
.
Author: =?UTF-8?Q?R=C3=B3bert_D=C3=A1vid?= <lrdxgm@gmail.com>
Date: Fri, 4 Oct 2013 16:02:35 -0700 (PDT)
Raw View
------=_Part_520_23226443.1380927755777
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
2013. okt=F3ber 4., p=E9ntek 22:32:30 UTC+2 id=F5pontban Magnus Fromreide a=
=20
k=F6vetkez=F5t =EDrta:
>
> On Fri, 2013-10-04 at 12:49 -0700, Daryle Walker wrote:=20
> > I figured out how to activate the web page feature of the GitHub=20
> > repository for my array proposal. It is at=20
> > http://ctmacuser.github.io/multiarray-iso-proposal. It should lead to=
=20
> > the copy of the proposal copied there from the regular branch.=20
> > =20
> > The next submission deadline is in a week, so I need a final check=20
> > over. Are there any mistakes or omissions? Is anything unclear?=20
>
> I think you need to put a lot more effort into the motivation section.=20
>
> Explain why this is something that is needed.=20
>
>
>
> In "Design Decisions" you are waving your hands trying to claim that=20
> operator[]() calls are inherently slower than calls to the built in=20
> operator[].=20
> Do you have any data to support this claim?=20
> Preferably data that support that it is infeasible to achieve the same=20
> performance.=20
> This is important as you are disabling user defined indexing for data=20
> stored in your class based on this.=20
>
I guess he referred to the std::array<X,n> implementation may have extra=20
data besides the element, so indexing std::array<std::array<X,n>,m> with=20
(a,b) "coordinates" isn't the same as indexing a X[n*m] with a*n+b.
=20
>
>
>
> I am strongly opposed to misappropriating the function call operator for=
=20
> indexing.=20
>
> std::array<int, 17> anArray;=20
> std::function<int(int)> fun(anArray);=20
>
> One can have lots of fun with that function call operator.=20
>
A multidimensional array needs to have multicoordinate indexing, otherwise=
=20
it is useless.
Before C++11, it was done using the function call operator, because it was=
=20
totally awkward to use operator[] (call syntax would been something like=20
my_array_obj[array_indexes(1,2,3)];). I haven't seen any multiarray/linalg=
=20
matrix library that started from zero using C++11, that's why all of them=
=20
still use operator(). But this is no reason to have this new proposed class=
=20
to use it.
As for operator[], the 'reference' implementation allows this, without any=
=20
error:
array_md<int, 2, 3> my2dArray;
my2dArray[{1,2,3,4}] =3D 42;
Instead of initializer_list (as you cannot restrict the accepted init list=
=20
size), I think it would be better to use std::array<size_type,=20
dimensionality> (or something equivalent) as the parameter for operator[].
Also, I find linear addresses of a multidim array error-prone. Instead, I'd=
=20
give a reshape() function that would allow us to reshape the contiguous=20
memory layout to another dimension (internally, that can be done with a=20
static_cast), then use it to reshape to an 1D array, then index it - with=
=20
the linear index. The idea is to do something like Matlab's reshape (it=20
does have linear indexing - and I get burned by that every now and then).
Regards, Robert
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_520_23226443.1380927755777
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>2013. okt=F3ber 4., p=E9ntek 22:32:30 UTC+2 id=F5p=
ontban Magnus Fromreide a k=F6vetkez=F5t =EDrta:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;">On Fri, 2013-10-04 at 12:49 -0700, Daryle Walker wrote:
<br>> I figured out how to activate the web page feature of the GitHub
<br>> repository for my array proposal. It is at
<br>> <a href=3D"http://ctmacuser.github.io/multiarray-iso-proposal" tar=
get=3D"_blank">http://ctmacuser.github.io/<wbr>multiarray-iso-proposal</a>.=
It should lead to
<br>> the copy of the proposal copied there from the regular branch.
<br>>
<br>> The next submission deadline is in a week, so I need a final check
<br>> over. Are there any mistakes or omissions? Is anything=
unclear?
<br>
<br>I think you need to put a lot more effort into the motivation section.
<br>
<br>Explain why this is something that is needed.
<br>
<br>
<br>
<br>In "Design Decisions" you are waving your hands trying to claim that
<br>operator[]() calls are inherently slower than calls to the built in
<br>operator[].
<br>Do you have any data to support this claim?
<br>Preferably data that support that it is infeasible to achieve the same
<br>performance.
<br>This is important as you are disabling user defined indexing for data
<br>stored in your class based on this.
<br></blockquote><div>I guess he referred to the std::array<X,n> impl=
ementation may have extra data besides the element, so indexing std::array&=
lt;std::array<X,n>,m> with (a,b) "coordinates" isn't the same as i=
ndexing a X[n*m] with a*n+b.<br> </div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;">
<br>
<br>
<br>I am strongly opposed to misappropriating the function call operator fo=
r
<br>indexing.
<br>
<br>std::array<int, 17> anArray;
<br>std::function<int(int)> fun(anArray);
<br>
<br>One can have lots of fun with that function call operator.
<br></blockquote><div>A multidimensional array needs to have multicoordinat=
e indexing, otherwise it is useless.<br><br>Before C++11, it was done using=
the function call operator, because it was totally awkward to use operator=
[] (call syntax would been something like my_array_obj[array_indexes(1,2,3)=
];). I haven't seen any multiarray/linalg matrix library that started from =
zero using C++11, that's why all of them still use operator(). But this is =
no reason to have this new proposed class to use it.<br><br>As for operator=
[], the 'reference' implementation allows this, without any error:<br><div =
class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border=
-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wr=
ap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #000;" class=3D"styled-by-prettify">array_md</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" clas=
s=3D"styled-by-prettify">2</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </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"> my2dArray</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span><code class=3D"=
prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">my2d=
Array</span><span style=3D"color: #660;" class=3D"styled-by-prettify"></spa=
n></code><span style=3D"color: #660;" class=3D"styled-by-prettify">[{</span=
><span style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"co=
lor: #066;" class=3D"styled-by-prettify">2</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">,</span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">3</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">,</span><span style=3D"color: #066;" class=3D"styled-by-pret=
tify">4</span><span style=3D"color: #660;" class=3D"styled-by-prettify">}] =
=3D 42;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span></div></code></div>Instead of initializer_list (as you cannot restr=
ict the accepted init list size), I think it would be better to use std::ar=
ray<size_type, dimensionality> (or something equivalent) as the param=
eter for operator[].<br><br>Also, I find linear addresses of a multidim arr=
ay error-prone. Instead, I'd give a reshape() function that would allow us =
to reshape the contiguous memory layout to another dimension (internally, t=
hat can be done with a static_cast), then use it to reshape to an 1D array,=
then index it - with the linear index. The idea is to do something like Ma=
tlab's reshape (it does have linear indexing - and I get burned by that eve=
ry now and then).<br><br>Regards, Robert<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_520_23226443.1380927755777--
.
Author: Daryle Walker <darylew@gmail.com>
Date: Sat, 5 Oct 2013 03:46:42 -0700 (PDT)
Raw View
------=_Part_1528_26644543.1380970002263
Content-Type: text/plain; charset=ISO-8859-1
On Friday, October 4, 2013 4:32:30 PM UTC-4, Magnus Fromreide wrote:
>
> On Fri, 2013-10-04 at 12:49 -0700, Daryle Walker wrote:
> > I figured out how to activate the web page feature of the GitHub
> > repository for my array proposal. It is at
> > http://ctmacuser.github.io/multiarray-iso-proposal. It should lead to
> > the copy of the proposal copied there from the regular branch.
> >
> > The next submission deadline is in a week, so I need a final check
> > over. Are there any mistakes or omissions? Is anything unclear?
>
> I think you need to put a lot more effort into the motivation section.
>
> Explain why this is something that is needed.
1. The current std::array wraps a built-in array into a Regular type.
Said wrapper also acts as a Standard (sequence) container.
2. Why use multi-dimensional arrays? I don't know; that's up to your
choices for the application.
3. The new std::array puts (1) and (2) together. It wraps a
multi-dimensional built-in array as a Regular type. Also, the element type
is what you originally specified, not some intermediate sub-array type.
4. Declaring and using a built-in array involves a (series of) bracketed
number. This isn't compatible with C++11's variadic stuff. The new
std::array's extent specification and dereference calls both use
comma-separated lists.
(See the reply to Robert David for your other questions.)
Daryle W.
--
---
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_1528_26644543.1380970002263
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, October 4, 2013 4:32:30 PM UTC-4, Magnus Fromre=
ide wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.=
8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-=
width: 1px; border-left-style: solid;">On Fri, 2013-10-04 at 12:49 -0700, D=
aryle Walker wrote:
<br>> I figured out how to activate the web page feature of the GitHub
<br>> repository for my array proposal. It is at
<br>> <a href=3D"http://ctmacuser.github.io/multiarray-iso-proposal" tar=
get=3D"_blank">http://ctmacuser.github.io/<wbr>multiarray-iso-proposal</a>.=
It should lead to
<br>> the copy of the proposal copied there from the regular branch.
<br>>
<br>> The next submission deadline is in a week, so I need a final check
<br>> over. Are there any mistakes or omissions? Is anything=
unclear?
<br>
<br>I think you need to put a lot more effort into the motivation section.
<br>
<br>Explain why this is something that is needed.
</blockquote><div> </div><ol><li>The current <font face=3D"courier new=
,monospace">std::array</font> wraps a built-in array into a Regular type.&n=
bsp; Said wrapper also acts as a Standard (sequence) container.</li><li>Why=
use multi-dimensional arrays? I don't know; that's up to your c=
hoices for the application.</li><li>The new <font face=3D"courier new,=
monospace">std::array</font> puts (1) and (2) together. It wraps a mu=
lti-dimensional built-in array as a Regular type. Also, the element t=
ype is what you originally specified, not some intermediate sub-array type.=
</li><li>Declaring and using a built-in array involves a (series of) bracke=
ted number. This isn't compatible with C++11's variadic stuff. =
The new <font face=3D"courier new,monospace">std::array</font>'s extent spe=
cification and dereference calls both use comma-separated lists.</li></ol><=
div>(See the reply to Robert David for your other questions.)</div><div>&nb=
sp;</div><div>Daryle W.</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1528_26644543.1380970002263--
.
Author: Daryle Walker <darylew@gmail.com>
Date: Sat, 5 Oct 2013 04:58:15 -0700 (PDT)
Raw View
------=_Part_1_11836790.1380974295152
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
On Friday, October 4, 2013 7:02:35 PM UTC-4, R=F3bert D=E1vid wrote:
>
> 2013. okt=F3ber 4., p=E9ntek 22:32:30 UTC+2 id=F5pontban Magnus Fromreide=
a=20
> k=F6vetkez=F5t =EDrta:
>>
>> On Fri, 2013-10-04 at 12:49 -0700, Daryle Walker wrote:=20
>> > I figured out how to activate the web page feature of the GitHub=20
>> > repository for my array proposal. It is at=20
>> > *http://ctmacuser.github.io/multiarray-iso-proposal*<http://ctmacuser.=
github.io/multiarray-iso-proposal>.=20
>> It should lead to=20
>> > the copy of the proposal copied there from the regular branch.=20
>> > =20
>> > The next submission deadline is in a week, so I need a final check=20
>> > over. Are there any mistakes or omissions? Is anything unclear?=20
>
> [SNIP]=20
> In "Design Decisions" you are waving your hands trying to claim that=20
>> operator[]() calls are inherently slower than calls to the built in=20
>> operator[].=20
>> Do you have any data to support this claim?=20
>> Preferably data that support that it is infeasible to achieve the same=
=20
>> performance.=20
>> This is important as you are disabling user defined indexing for data=20
>> stored in your class based on this.=20
>>
> I guess he referred to the std::array<X,n> implementation may have extra=
=20
> data besides the element, so indexing std::array<std::array<X,n>,m> with=
=20
> (a,b) "coordinates" isn't the same as indexing a X[n*m] with a*n+b.=20
>
=20
It doesn't have to be extra data; extra padding alone can be a=20
disadvantage. But I was talking about calling a member operator of a class=
=20
versus a built-in operator, although inline-based optimizations can remove=
=20
the difference. But why hope for optimization when I can avoid the need=20
under some circumstances?
=20
The new array doesn't support user-defined indexing because built-in arrays=
=20
don't. It's not an every-feature class. And how would the user-defined=20
indexing be submitted to the class? Where would it be stored? How could=
=20
either not break the std::array interface? Why should users who never need=
=20
index order scrambling have to pay for it?
=20
Someone from the previous discussion wanted configurable indexing too. I=
=20
am coming up with an adaptor class template for this, like stack or queue. =
=20
There's no size-changing methods, just multi-coordinate access and storing=
=20
the extents and index-priorities. (The container is protected, so you can=
=20
make a derived class if you need to add size-changing methods.)
=20
> I am strongly opposed to misappropriating the function call operator for=
=20
>> indexing.=20
>>
>> std::array<int, 17> anArray;=20
>> std::function<int(int)> fun(anArray);=20
>>
>> One can have lots of fun with that function call operator.=20
>>
> A multidimensional array needs to have multicoordinate indexing, otherwis=
e=20
> it is useless.
>
> Before C++11, it was done using the function call operator, because it wa=
s=20
> totally awkward to use operator[] (call syntax would been something like=
=20
> my_array_obj[array_indexes(1,2,3)];). I haven't seen any multiarray/linal=
g=20
> matrix library that started from zero using C++11, that's why all of them=
=20
> still use operator(). But this is no reason to have this new proposed cla=
ss=20
> to use it.
>
=20
operator[] always only takes one argument, so multi-coordinate indexing=20
would need to submit a tuple object. Or use operator() instead (or along=
=20
with). C++11 adds to the syntax of operator[] to take a braced-list. You=
=20
have to create an operator[] overload that takes a type that's compatible=
=20
with a braced-list. I chose std::initializer_list since that is what the=
=20
example used.
=20
Can you clarify what "any multiarray/linalg matrix library that started=20
from zero" means?
=20
> As for operator[], the 'reference' implementation allows this, without an=
y=20
> error:
> array_md<int, 2, 3> my2dArray;
> my2dArray[{1,2,3,4}] =3D 42;
> Instead of initializer_list (as you cannot restrict the accepted init lis=
t=20
> size), I think it would be better to use std::array<size_type,=20
> dimensionality> (or something equivalent) as the parameter for operator[]=
..
>
=20
For the current containers, at() throws when given a bad index, while=20
operator[] tries to use it even when it causes Undefined Behavior. My=20
operator[] does the same thing; it forfeits checking the list length or the=
=20
individual values, even if it causes a crash. Use at() again to check=20
those and throw if they're found wanting, but forfeit speed due to those=20
checks.
=20
Someone from the previous discussion brought up using std::array<std::size_=
t,=20
extent_count> as the index type for tuple-enabled operator[]. He also=20
mentioned the down side. We get an error if too many items are in the=20
initializer, but not if there are too few. In the latter case, the missing=
=20
elements will be zero instead of causing an error. There's also the=20
cosmetic issue of a double brace pair is sometimes needed for a std::array"=
literal" because brace-elision isn't always accepted. (And it's weird to=
=20
use std::array as a helper type since this code will be redefining array!)
=20
> Also, I find linear addresses of a multidim array error-prone. Instead,=
=20
> I'd give a reshape() function that would allow us to reshape the contiguo=
us=20
> memory layout to another dimension (internally, that can be done with a=
=20
> static_cast), then use it to reshape to an 1D array, then index it - with=
=20
> the linear index. The idea is to do something like Matlab's reshape (it=
=20
> does have linear indexing - and I get burned by that every now and then).
>
=20
For "linear addresses of a multidim array," are you talking about the begin=
/
end functions? Without those, you can't use an array with Standard=20
algorithms or range-for, or meet the Container requirements. Your kind of=
=20
reshaping would require a pointer or reference reinterpret_cast, especially=
=20
since built-in arrays don't support static_cast at all. (A static_castwoul=
d be more appropriate for changing the element type, not the extent=20
layout.) And what would happen if the source and destination type have=20
different total element counts? Or would such conversions be blocked? A=
=20
copy seems better all around, and I can change element type and/or count at=
=20
the same time. The linear order lets me define how elements transfer=20
locations when the source and destination extent tuples are not equal. (A=
=20
specification of randomly scrambled order wouldn't be too useful.)
=20
Besides one-dimensional arrays, you can't really get linear access outside=
=20
of explicitly messing around with a copy of the return value from begin or=
=20
data.
=20
Daryle W.
=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1_11836790.1380974295152
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, October 4, 2013 7:02:35 PM UTC-4, R=F3bert D=E1=
vid wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.=
8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-=
width: 1px; border-left-style: solid;"><div dir=3D"ltr">2013. okt=F3ber 4.,=
p=E9ntek 22:32:30 UTC+2 id=F5pontban Magnus Fromreide a k=F6vetkez=F5t =ED=
rta:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; p=
adding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width:=
1px; border-left-style: solid;">On Fri, 2013-10-04 at 12:49 -0700, Daryle =
Walker wrote: <br>> I figured out how to activate the web page feature o=
f the GitHub <br>> repository for my array proposal. It is at <br>=
> <a href=3D"http://ctmacuser.github.io/multiarray-iso-proposal" target=
=3D"_blank"><u><font color=3D"#0066cc">http://ctmacuser.github.io/<wbr>mult=
iarray-iso-proposal</font></u></a>. It should lead to <br>> the co=
py of the proposal copied there from the regular branch. <br>> <b=
r>> The next submission deadline is in a week, so I need a final check <=
br>> over. Are there any mistakes or omissions? Is anything =
unclear? </blockquote></div></blockquote><div>[SNIP] </div><blockquote=
class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1e=
x; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-le=
ft-style: solid;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(20=
4, 204, 204); border-left-width: 1px; border-left-style: solid;">In "Design=
Decisions" you are waving your hands trying to claim that <br>operator[]()=
calls are inherently slower than calls to the built in <br>operator[]. <br=
>Do you have any data to support this claim? <br>Preferably data that suppo=
rt that it is infeasible to achieve the same <br>performance. <br>This is i=
mportant as you are disabling user defined indexing for data <br>stored in =
your class based on this. <br></blockquote><div>I guess he referred to the =
std::array<X,n> implementation may have extra data besides the elemen=
t, so indexing std::array<std::array<X,n>,m> with (a,b) "coordi=
nates" isn't the same as indexing a X[n*m] with a*n+b. </div></div></b=
lockquote><div> </div><div>It doesn't have to be extra data; extra pad=
ding alone can be a disadvantage. But I was talking about callin=
g a member operator of a class versus a built-in operator, although in=
line-based optimizations can remove the difference. But why hope for =
optimization when I can avoid the need under some circumstances?</div><div>=
</div><div>The new <font face=3D"courier new,monospace">array</font> =
doesn't support user-defined indexing because built-in arrays don't. =
It's not an every-feature class. And how would the user-defined =
indexing be submitted to the class? Where would it be stored? H=
ow could either not break the <font face=3D"courier new,monospace">std::arr=
ay</font> interface? Why should users who never need index order scra=
mbling have to pay for it?</div><div> </div><div>Someone from the prev=
ious discussion wanted configurable indexing too. I am coming up with=
an adaptor class template for this, like <font face=3D"courier new,monospa=
ce">stack</font> or <font face=3D"courier new,monospace">queue</font>. =
; There's no size-changing methods, just multi-coordinate access and storin=
g the extents and index-priorities. (The container is <font face=3D"c=
ourier new,monospace">protected</font>, so you can make a derived class if =
you need to add size-changing methods.)</div><div> </div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex;=
border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left=
-style: solid;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D=
"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, =
204, 204); border-left-width: 1px; border-left-style: solid;">I am strongly=
opposed to misappropriating the function call operator for <br>indexing. <=
br><br>std::array<int, 17> anArray; <br>std::function<int(int)>=
fun(anArray); <br><br>One can have lots of fun with that function call ope=
rator. <br></blockquote><div>A multidimensional array needs to have multico=
ordinate indexing, otherwise it is useless.<br><br>Before C++11, it was don=
e using the function call operator, because it was totally awkward to use o=
perator[] (call syntax would been something like my_array_obj[array_indexes=
(1,<wbr>2,3)];). I haven't seen any multiarray/linalg matrix library that s=
tarted from zero using C++11, that's why all of them still use operator(). =
But this is no reason to have this new proposed class to use it.</div></div=
></blockquote><div> </div><div><font face=3D"courier new,monospace">op=
erator[]</font> always only takes one argument, so multi-coordinate indexin=
g would need to submit a tuple object. Or use <font face=3D"courier n=
ew,monospace">operator()</font> instead (or along with). C++11 adds t=
o the syntax of <font face=3D"courier new,monospace">operator[]</font> to t=
ake a braced-list. You have to create an <font face=3D"courier new,mo=
nospace">operator[]</font> overload that takes a type that's compatible wit=
h a braced-list. I chose <font face=3D"courier new,monospace">std::in=
itializer_list</font> since that is what the example used.</div><div> =
</div><div>Can you clarify what "any multiarray/linalg matrix library =
that started from zero" means?</div><div> </div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-l=
eft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: s=
olid;"><div dir=3D"ltr"><div>As for operator[], the 'reference' implementat=
ion allows this, without any error:<br><div style=3D"border: 1px solid rgb(=
187, 187, 187); word-wrap: break-word; background-color: rgb(250, 250, 250)=
;"><code><div><span style=3D"color: rgb(0, 0, 0);">array_md</span><span sty=
le=3D"color: rgb(102, 102, 0);"><</span><span style=3D"color: rgb(0, 0, =
136);">int</span><span style=3D"color: rgb(102, 102, 0);">,</span><span sty=
le=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 102, 102);=
">2</span><span style=3D"color: rgb(102, 102, 0);">,</span><span style=3D"c=
olor: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 102, 102);">3</sp=
an><span style=3D"color: rgb(102, 102, 0);">></span><span style=3D"color=
: rgb(0, 0, 0);"> my2dArray</span><span style=3D"color: rgb(102, 102, 0);">=
;</span><span style=3D"color: rgb(0, 0, 0);"><br></span><code><span style=
=3D"color: rgb(0, 0, 0);">my2dArray</span><span style=3D"color: rgb(102, 10=
2, 0);"></span></code><span style=3D"color: rgb(102, 102, 0);">[{</span><sp=
an style=3D"color: rgb(0, 102, 102);">1</span><span style=3D"color: rgb(102=
, 102, 0);">,</span><span style=3D"color: rgb(0, 102, 102);">2</span><span =
style=3D"color: rgb(102, 102, 0);">,</span><span style=3D"color: rgb(0, 102=
, 102);">3</span><span style=3D"color: rgb(102, 102, 0);">,</span><span sty=
le=3D"color: rgb(0, 102, 102);">4</span><span style=3D"color: rgb(102, 102,=
0);">}] =3D 42;</span><span style=3D"color: rgb(0, 0, 0);"><br></span></di=
v></code></div>Instead of initializer_list (as you cannot restrict the acce=
pted init list size), I think it would be better to use std::array<size_=
type, dimensionality> (or something equivalent) as the parameter for ope=
rator[].</div></div></blockquote><div> </div><div>For the current cont=
ainers, <font face=3D"courier new,monospace">at()</font> throws when given =
a bad index, while <font face=3D"courier new,monospace">operator[]</font> t=
ries to use it even when it causes Undefined Behavior. My <font face=
=3D"courier new,monospace">operator[]</font> does the same thing; it forfei=
ts checking the list length or the individual values, even if it causes a c=
rash. Use <font face=3D"courier new,monospace">at()</font> again to c=
heck those and throw if they're found wanting, but forfeit speed due to tho=
se checks.</div><div> </div><div>Someone from the previous discussion =
brought up using <font face=3D"courier new,monospace">std::array<st=
d::size_t, extent_count></font> as the index type for tuple-enabled <fon=
t face=3D"courier new,monospace">operator[]</font>. He also mentioned=
the down side. We get an error if too many items are in the initiali=
zer, but not if there are too few. In the latter case, the missing el=
ements will be zero instead of causing an error. There's also the cos=
metic issue of a double brace pair is sometimes needed for a <font face=3D"=
courier new,monospace">std::array</font> "literal" because brace-elision is=
n't always accepted. (And it's weird to use <font face=3D"courier new=
,monospace">std::array</font> as a helper type since this code will be rede=
fining <font face=3D"courier new,monospace">array</font>!)</div><div> =
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex;=
padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-widt=
h: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>Also, I find linea=
r addresses of a multidim array error-prone. Instead, I'd give a reshape() =
function that would allow us to reshape the contiguous memory layout to ano=
ther dimension (internally, that can be done with a static_cast), then use =
it to reshape to an 1D array, then index it - with the linear index. The id=
ea is to do something like Matlab's reshape (it does have linear indexing -=
and I get burned by that every now and then).</div></div></blockquote><div=
> </div><div>For "linear addresses of a multidim array," are you talki=
ng about the <font face=3D"courier new,monospace">begin</font>/<font f=
ace=3D"courier new,monospace">end</font> functions? Without those, yo=
u can't use an <font face=3D"courier new,monospace">array</font> with Stand=
ard algorithms or range-<font face=3D"courier new,monospace">for</font>, or=
meet the Container requirements. Your kind of reshaping would requir=
e a pointer or reference <font face=3D"courier new,monospace">reinterp=
ret_cast</font>, especially since built-in arrays don't support <font face=
=3D"courier new,monospace">static_cast</font> at all. (A <font face=
=3D"courier new,monospace">static_cast</font> would be more appropriate for=
changing the element type, not the extent layout.) And what would ha=
ppen if the source and destination type have different total element counts=
? Or would such conversions be blocked? A copy seems bette=
r all around, and I can change element type and/or count at the same time.&=
nbsp; The linear order lets me define how elements transfer locations when =
the source and destination extent tuples are not equal. (A specificat=
ion of randomly scrambled order wouldn't be too useful.)</div><div> </=
div><div>Besides one-dimensional <font face=3D"courier new,monospace">array=
</font>s, you can't really get linear access outside of explicitly messing =
around with a copy of the return value from <font face=3D"courier new,=
monospace">begin</font> or <font face=3D"courier new,monospace">data</font>=
..</div><div> </div><div>Daryle W.</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1_11836790.1380974295152--
.
Author: morwenn29@gmail.com
Date: Sat, 5 Oct 2013 11:17:33 -0700 (PDT)
Raw View
------=_Part_1065_12434343.1380997053539
Content-Type: text/plain; charset=ISO-8859-1
It's stillpossible to create a new multi-index standard type, let's say
std::index<>, which would more or less be like this:
I tried to use it the way you wanted to. I works fine and static_assert is
triggered when needed, allowing a meaningful
error message.
http://coliru.stacked-crooked.com/a/c678edd816def10d
--
---
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_1065_12434343.1380997053539
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It's stillpossible to create a new multi-index standard ty=
pe, let's say std::index<>, which would more or less be like this:<br=
>I tried to use it the way you wanted to. I works fine and static_assert is=
triggered when needed, allowing a meaningful<br>error message.<br><br>http=
://coliru.stacked-crooked.com/a/c678edd816def10d<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1065_12434343.1380997053539--
.
Author: =?UTF-8?Q?R=C3=B3bert_D=C3=A1vid?= <lrdxgm@gmail.com>
Date: Sun, 6 Oct 2013 15:13:55 -0700 (PDT)
Raw View
------=_Part_1814_24804129.1381097635275
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
2013. okt=F3ber 5., szombat 13:58:15 UTC+2 id=F5pontban Daryle Walker a=20
k=F6vetkez=F5t =EDrta:
=20
> Can you clarify what "any multiarray/linalg matrix library that started=
=20
> from zero" means?
>
Just a library that does not have any legacy features from the age before=
=20
C++11, don't think too much into this :)
For the current containers, at() throws when given a bad index, while=20
> operator[] tries to use it even when it causes Undefined Behavior. My=20
> operator[] does the same thing; it forfeits checking the list length or=
=20
> the individual values, even if it causes a crash. Use at() again to=20
> check those and throw if they're found wanting, but forfeit speed due to=
=20
> those checks.
>
Your reference implementation adds a run-time check not just for=20
out-of-range indexing, but also for the amount of indexes. That should be a=
=20
compile-time error, for both operator[] and at().
=20
> Someone from the previous discussion brought up using std::array<std::siz=
e_t,=20
> extent_count> as the index type for tuple-enabled operator[]. He also=20
> mentioned the down side. We get an error if too many items are in the=20
> initializer, but not if there are too few. In the latter case, the missi=
ng=20
> elements will be zero instead of causing an error. There's also the=20
> cosmetic issue of a double brace pair is sometimes needed for a std::arra=
y"literal" because brace-elision isn't always accepted. (And it's weird to=
=20
> use std::array as a helper type since this code will be redefining array!=
)
>
Yeah, but this helper is a 1D array. 1D arrays will still have a=20
operator[](size_t) parameter, at least because of compatibility.
=20
> =20
>
>> Also, I find linear addresses of a multidim array error-prone. Instead,=
=20
>> I'd give a reshape() function that would allow us to reshape the contigu=
ous=20
>> memory layout to another dimension (internally, that can be done with a=
=20
>> static_cast), then use it to reshape to an 1D array, then index it - wit=
h=20
>> the linear index. The idea is to do something like Matlab's reshape (it=
=20
>> does have linear indexing - and I get burned by that every now and then)=
..
>>
> =20
> For "linear addresses of a multidim array," are you talking about the=20
> begin/end functions?
>
No. An operator[](size_t). That should be given only for 1D arrays, I=20
believe. While at it, I think begin() and end() also should give an=20
iterator to an array with one-less extents (except for 1D arrays):=20
similarly to=20
int a[][][] =3D {...}
begin(a);
giving a pointer to int[][]. I think it is both more logical, and=20
compatible with built-in arrays with multiple extents.
And what would happen if the source and destination type have different=20
> total element counts? Or would such conversions be blocked?
>
Blocked, of course. Using the same memory are for items of different size=
=20
and/or amount is going straight against any type system. (((((Although:=20
what about array<uint8_t, 4> vs array<_simd_vector_of_4_uint8, 1>?)))))
If one needs that, make a copy (rather, being different type, make a=20
conversion).
=20
> A copy seems better all around, and I can change element type and/or=20
> count at the same time.
>
I think it is quite bad to have my 3D array to be viewed in a 1D or 2D=20
fashion, I need to make a copy.. (Alternatively to this reshape, an=20
appropriate array_view could be a good solution as well.)
Regards, Robert
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1814_24804129.1381097635275
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>2013. okt=F3ber 5., szombat 13:58:15 UTC+2 id=F5po=
ntban Daryle Walker a k=F6vetkez=F5t =EDrta:<br><div> <br></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Can you clarif=
y what "any multiarray/linalg matrix library that started from zero" m=
eans?</div></div></blockquote><div>Just a library that does not have any le=
gacy features from the age before C++11, don't think too much into this :)<=
br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div>For the current containers, <font face=3D"courier new,monospace">at()<=
/font> throws when given a bad index, while <font face=3D"courier new,monos=
pace">operator[]</font> tries to use it even when it causes Undefined Behav=
ior. My <font face=3D"courier new,monospace">operator[]</font> does t=
he same thing; it forfeits checking the list length or the individual value=
s, even if it causes a crash. Use <font face=3D"courier new,monospace=
">at()</font> again to check those and throw if they're found wanting, but =
forfeit speed due to those checks.</div></div></blockquote><div>Your refere=
nce implementation adds a run-time check not just for out-of-range indexing=
, but also for the amount of indexes. That should be a compile-time error, =
for both operator[] and at().<br> <br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><div>Someone from the previous discussi=
on brought up using <font face=3D"courier new,monospace">std::array<=
;std::size_t, extent_count></font> as the index type for tuple-enabled <=
font face=3D"courier new,monospace">operator[]</font>. He also mentio=
ned the down side. We get an error if too many items are in the initi=
alizer, but not if there are too few. In the latter case, the missing=
elements will be zero instead of causing an error. There's also the =
cosmetic issue of a double brace pair is sometimes needed for a <font face=
=3D"courier new,monospace">std::array</font> "literal" because brace-elisio=
n isn't always accepted. (And it's weird to use <font face=3D"courier=
new,monospace">std::array</font> as a helper type since this code will be =
redefining <font face=3D"courier new,monospace">array</font>!)</div></div><=
/blockquote><div>Yeah, but this helper is a 1D array. 1D arrays will still =
have a operator[](size_t) parameter, at least because of compatibility.<br>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div> </div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-lef=
t-width:1px;border-left-style:solid"><div dir=3D"ltr"><div>Also, I find lin=
ear addresses of a multidim array error-prone. Instead, I'd give a reshape(=
) function that would allow us to reshape the contiguous memory layout to a=
nother dimension (internally, that can be done with a static_cast), then us=
e it to reshape to an 1D array, then index it - with the linear index. The =
idea is to do something like Matlab's reshape (it does have linear indexing=
- and I get burned by that every now and then).</div></div></blockquote><d=
iv> </div><div>For "linear addresses of a multidim array," are you tal=
king about the <font face=3D"courier new,monospace">begin</font>/<font=
face=3D"courier new,monospace">end</font> functions?</div></div></blockquo=
te><div>No. An operator[](size_t). That should be given only for 1D arrays,=
I believe. While at it, I think begin() and end() also should give an iter=
ator to an array with one-less extents (except for 1D arrays): similarly to=
<br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 25=
0); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1p=
x; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpre=
ttyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">int</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> a</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">[][][]</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{...}</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">begin</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">a=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div><=
/code></div>giving a pointer to int[][]. I think it is both more logical, a=
nd compatible with built-in arrays with multiple extents.<br><br></div><blo=
ckquote 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>And what wou=
ld happen if the source and destination type have different total element c=
ounts? Or would such conversions be blocked?</div></div></blockquote>=
<div>Blocked, of course. Using the same memory are for items of different s=
ize and/or amount is going straight against any type system. (((((Although:=
what about array<uint8_t, 4> vs array<_simd_vector_of_4_uint8, 1&=
gt;?)))))<br>If one needs that, make a copy (rather, being different type, =
make a conversion).<br> <br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><div> A copy seems better all around, =
and I can change element type and/or count at the same time.</div></div></b=
lockquote><div>I think it is quite bad to have my 3D array to be viewed in =
a 1D or 2D fashion, I need to make a copy.. (Alternatively to this reshape,=
an appropriate array_view could be a good solution as well.)<br><br>Regard=
s, Robert<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1814_24804129.1381097635275--
.
Author: Daryle Walker <darylew@gmail.com>
Date: Thu, 10 Oct 2013 07:12:22 -0700 (PDT)
Raw View
------=_Part_154_27407089.1381414342720
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
On Sunday, October 6, 2013 6:13:55 PM UTC-4, R=F3bert D=E1vid wrote:
>
> 2013. okt=F3ber 5., szombat 13:58:15 UTC+2 id=F5pontban Daryle Walker a=
=20
> k=F6vetkez=F5t =EDrta:
>
>> For the current containers, at() throws when given a bad index, while=20
>> operator[] tries to use it even when it causes Undefined Behavior. My=
=20
>> operator[] does the same thing; it forfeits checking the list length or=
=20
>> the individual values, even if it causes a crash. Use at() again to=20
>> check those and throw if they're found wanting, but forfeit speed due to=
=20
>> those checks.
>>
> Your reference implementation adds a run-time check not just for=20
> out-of-range indexing, but also for the amount of indexes. That should be=
a=20
> compile-time error, for both operator[] and at().
>
=20
at() throws on index value errors and, for the std::initializer_listoverloa=
d, index amount errors. The length is a run-time attribute; it=20
cannot be checked to become a compile-time error.
=20
The overloads of at() and operator() that take individual indexes=20
already have a static_assert if there are too many indexes. But my=20
proposal has an enable_if or equivalent instead. Fewer indexes is OK; the=
=20
code stops at the appropriate level and returns a (built-in) inner array. =
=20
You can omit all indexes to get a reference to the (array) data object. =20
(It's your only choice when there are no extents.)
=20
> Also, I find linear addresses of a multidim array error-prone. Instead,=
=20
> I'd give a reshape() function that would allow us to reshape the contiguo=
us=20
> memory layout to another dimension (internally, that can be done with a=
=20
> static_cast), then use it to reshape to an 1D array, then index it - with=
=20
> the linear index. The idea is to do something like Matlab's reshape (it=
=20
> does have linear indexing - and I get burned by that every now and then).
>
>> =20
>> For "linear addresses of a multidim array," are you talking about the=20
>> begin/end functions?
>>
> No. An operator[](size_t). That should be given only for 1D arrays, I=20
> believe. While at it, I think begin() and end() also should give an=20
> iterator to an array with one-less extents (except for 1D arrays):=20
> similarly to=20
> int a[][][] =3D {...}
> begin(a);
> giving a pointer to int[][]. I think it is both more logical, and=20
> compatible with built-in arrays with multiple extents.
>
=20
Having new std::array be a container of T, instead of some (possibly=20
multidimensional) array-of-T, is one of the main points of the class. Most=
=20
of the functions work in units of T instead of a type users usually won't=
=20
care about. (And remember, array types have limited functionality. =20
Another one of the points of std::array is to provided a wrapper that makes=
=20
arrays a Regular type.)
=20
You can use array<remove_extent_t<ArrayType>, extent<ArrayType>::value>,=20
where ArrayType is the built-in array type you're using, to get this effect=
..
=20
> And what would happen if the source and destination type have different=
=20
>> total element counts? Or would such conversions be blocked?
>
> Blocked, of course. Using the same memory are for items of different size=
=20
> and/or amount is going straight against any type system. (((((Although:=
=20
> what about array<uint8_t, 4> vs array<_simd_vector_of_4_uint8, 1>?)))))
> If one needs that, make a copy (rather, being different type, make a=20
> conversion).
> =20
>
>> A copy seems better all around, and I can change element type and/or=
=20
>> count at the same time.
>>
> I think it is quite bad to have my 3D array to be viewed in a 1D or 2D=20
> fashion, I need to make a copy.. (Alternatively to this reshape, an=20
> appropriate array_view could be a good solution as well.)
>
=20
To transform arrays with different ranks, you have to explicitly call=20
reshape_array to make a copy; it happens when the user actually wants it,=
=20
not by accident. If you want to reshape at the view level, something like=
=20
reinterpret_cast<T(&)[the][new][shape]>(my_array()) should work.
=20
Daryle W.
=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_154_27407089.1381414342720
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, October 6, 2013 6:13:55 PM UTC-4, R=F3bert D=E1=
vid wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.=
8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-=
width: 1px; border-left-style: solid;"><div dir=3D"ltr">2013. okt=F3ber 5.,=
szombat 13:58:15 UTC+2 id=F5pontban Daryle Walker a k=F6vetkez=F5t =EDrta:=
<br><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; p=
adding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width:=
1px; border-left-style: solid;"><div dir=3D"ltr"><div>For the current cont=
ainers, <font face=3D"courier new,monospace">at()</font> throws when given =
a bad index, while <font face=3D"courier new,monospace">operator[]</font> t=
ries to use it even when it causes Undefined Behavior. My <font face=
=3D"courier new,monospace">operator[]</font> does the same thing; it forfei=
ts checking the list length or the individual values, even if it causes a c=
rash. Use <font face=3D"courier new,monospace">at()</font> again to c=
heck those and throw if they're found wanting, but forfeit speed due to tho=
se checks.</div></div></blockquote><div>Your reference implementation adds =
a run-time check not just for out-of-range indexing, but also for the amoun=
t of indexes. That should be a compile-time error, for both operator[] and =
at().</div></div></blockquote><div> </div><div><font face=3D"courier n=
ew,monospace">at()</font> throws on index value errors and, for the <font f=
ace=3D"courier new,monospace">std::initializer_list</font> overload, index =
amount errors. The length is a run-time attribute; it cannot be check=
ed to become a compile-time error.</div><div> </div><div>The=
overloads of <font face=3D"courier new,monospace">at()</font> and <font fa=
ce=3D"courier new,monospace">operator()</font> that take individual indexes=
already have a <font face=3D"courier new,monospace">static_assert</fo=
nt> if there are too many indexes. But my proposal has an <font face=
=3D"courier new,monospace">enable_if</font> or equivalent instead. Fe=
wer indexes is OK; the code stops at the appropriate level and returns a (b=
uilt-in) inner array. You can omit all indexes to get a reference to =
the (array) data object. (It's your only choice when there are n=
o extents.)</div><div> </div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(20=
4, 204, 204); border-left-width: 1px; border-left-style: solid;"><div dir=
=3D"ltr"><div>Also, I find linear addresses of a multidim array error-prone=
.. Instead, I'd give a reshape() function that would allow us to reshape the=
contiguous memory layout to another dimension (internally, that can be don=
e with a static_cast), then use it to reshape to an 1D array, then index it=
- with the linear index. The idea is to do something like Matlab's reshape=
(it does have linear indexing - and I get burned by that every now and the=
n).</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8=
ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-w=
idth: 1px; border-left-style: solid;"><div dir=3D"ltr"><div> </div><di=
v>For "linear addresses of a multidim array," are you talking about th=
e <font face=3D"courier new,monospace">begin</font>/<font face=3D"courier n=
ew,monospace">end</font> functions?</div></div></blockquote><div>No. An ope=
rator[](size_t). That should be given only for 1D arrays, I believe. While =
at it, I think begin() and end() also should give an iterator to an array w=
ith one-less extents (except for 1D arrays): similarly to <br><div style=3D=
"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-co=
lor: rgb(250, 250, 250);"><code><div><span style=3D"color: rgb(0, 0, 136);"=
>int</span><span style=3D"color: rgb(0, 0, 0);"> a</span><span style=3D"col=
or: rgb(102, 102, 0);">[][][]</span><span style=3D"color: rgb(0, 0, 0);"> <=
/span><span style=3D"color: rgb(102, 102, 0);">=3D</span><span style=3D"col=
or: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(102, 102, 0);">{...}</=
span><span style=3D"color: rgb(0, 0, 0);"><br></span><span style=3D"color: =
rgb(0, 0, 136);">begin</span><span style=3D"color: rgb(102, 102, 0);">(</sp=
an><span style=3D"color: rgb(0, 0, 0);">a</span><span style=3D"color: rgb(1=
02, 102, 0);">);</span><span style=3D"color: rgb(0, 0, 0);"><br></span></di=
v></code></div>giving a pointer to int[][]. I think it is both more logical=
, and compatible with built-in arrays with multiple extents.</div></div></b=
lockquote><div> </div><div>Having new <font face=3D"courier new,monosp=
ace">std::array</font> be a container of T, instead of some (possibly multi=
dimensional) array-of-T, is one of the main points of the class. Most=
of the functions work in units of T instead of a type users usually won't =
care about. (And remember, array types have limited functionality.&nb=
sp; Another one of the points of <font face=3D"courier new,monospace">std::=
array</font> is to provided a wrapper that makes arrays a Regular type=
..)</div><div> </div><div>You can use <font face=3D"courier new,monospa=
ce">array<remove_extent_t<ArrayType>, extent<ArrayType>::val=
ue></font>, where <font face=3D"courier new,monospace">ArrayType</font> =
is the built-in array type you're using, to get this effect.</div><div>&nbs=
p;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8e=
x; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-wi=
dth: 1px; border-left-style: solid;"><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(2=
04, 204, 204); border-left-width: 1px; border-left-style: solid;">And what =
would happen if the source and destination type have different total elemen=
t counts? Or would such conversions be blocked?</blockquote><div dir=
=3D"ltr">Blocked, of course. Using the same memory are for items of differe=
nt size and/or amount is going straight against any type system. (((((Altho=
ugh: what about array<uint8_t, 4> vs array<_simd_vector_of_4_uint8=
, 1>?)))))<br>If one needs that, make a copy (rather, being different ty=
pe, make a conversion).<br> <br></div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color:=
rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;" dir=
=3D"ltr"><div dir=3D"ltr"><div> A copy seems better all around, =
and I can change element type and/or count at the same time.</div></div></b=
lockquote><div dir=3D"ltr">I think it is quite bad to have my 3D array to b=
e viewed in a 1D or 2D fashion, I need to make a copy.. (Alternatively to t=
his reshape, an appropriate array_view could be a good solution as well.)</=
div></blockquote><div> </div><div>To transform arrays with d=
ifferent ranks, you have to explicitly call <font face=3D"courier new,monos=
pace">reshape_array</font> to make a copy; it happens when the user actuall=
y wants it, not by accident. If you want to reshape at the view level=
, something like <font face=3D"courier new,monospace">reinterpret_cast<T=
(&)[the][new][shape]>(my_array())</font> should work.</div><div>&nbs=
p;</div><div>Daryle W.</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_154_27407089.1381414342720--
.