View mode: basic / threaded / horizontal-split · Log in · Help
June 14, 2004
Re: array assignment overloading change to opIndexAssign()
"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message
news:calav2$2lmo$1@digitaldaemon.com...
> In article <cabiqn$9a9$2@digitaldaemon.com>, Walter says...
> >
> >
> >"Sean Kelly" <sean@f4.ca> wrote in message
> >news:ca9ulq$o30$1@digitaldaemon.com...
> >> In article <ca9q2r$gfg$1@digitaldaemon.com>, Stewart Gordon says...
> >> >
> >> >Walter wrote:
> >> >> I'm going to change this to use opIndexAssign() rather than opIndex();
> >the
> >> >> latter will now only be used as array rvalues. This is necessary to
> >support
> >> >> multi-index arrays. So, replace:
> >> >>
> >> >>     T opIndex(int index, V value) { ... }
> >> >>
> >> >> with:
> >> >>
> >> >>     T opIndexAssign(V value, int index) { ... }
> >> >
> >> >Why swap the arguments over?  To confuse people?  Or does it somehow
> >> >simplify the extension to multi-indexes?
> >>
> >> T opIndexAssign(V value, int index1, int index2, int index3, ...) {}
> >
> >Maybe it should be:
> >
> >T opIndexAssign(int index1, int index2, int index3, ... , V value) {}
>
>
> Depending on the future of multi-dim arrays, is there a need for:
>
> T opIndexAssign(Value V, int i1, int i2, int i3); // X3
> T opIndexAssign(Value V, int i1, int i2); // X2
> T opIndexAssign(Value V, int i1); // X1
>
> .. on the same array?  I.e. the X1 model would return a two-dim slice of the
> original?  If so, maybe Value should be first for symmetry.

Good point.

Presumably the higher order overloads are slices, and the lowest is for accessing
the actual cell/element?
June 15, 2004
Re: array assignment overloading change to opIndexAssign()
Kevin Bealer wrote:

> Depending on the future of multi-dim arrays, is there a need for:
> 
> T opIndexAssign(Value V, int i1, int i2, int i3); // X3
> T opIndexAssign(Value V, int i1, int i2); // X2
> T opIndexAssign(Value V, int i1); // X1
> 
> .. on the same array?  I.e. the X1 model would return a two-dim slice of
> the
> original?  If so, maybe Value should be first for symmetry.

That depends very much on what kind of array you implement. The
language-supported arrays that I'm proposing in my draft allow indexing and
slicing only for exactly the same dimensionality as the array. For indexing
only certain dimensions, you will have to do something like

       int[3,3,3] A = ...;
       int[3,3] B = A[1,,];

So for these arrays, the answer to your question would be "no". Anyhow: the
overloaded opIndexAssign is meant to be flexible to be used in all kinds of
data-structures. Who knows when somebody finds a use for different numbers
of indices in some data-structure?
June 15, 2004
Re: array assignment overloading change to opIndexAssign()
In article <calc77$2nf4$1@digitaldaemon.com>, Matthew says...
>
>
>"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message
>news:calav2$2lmo$1@digitaldaemon.com...
>> In article <cabiqn$9a9$2@digitaldaemon.com>, Walter says...
>> >
>> >
>> >"Sean Kelly" <sean@f4.ca> wrote in message
>> >news:ca9ulq$o30$1@digitaldaemon.com...
>> >> In article <ca9q2r$gfg$1@digitaldaemon.com>, Stewart Gordon says...
>> >> >
>> >> >Walter wrote:
>> >> >> I'm going to change this to use opIndexAssign() rather than opIndex();
>> >the
>> >> >> latter will now only be used as array rvalues. This is necessary to
>> >support
>> >> >> multi-index arrays. So, replace:
>> >> >>
>> >> >>     T opIndex(int index, V value) { ... }
>> >> >>
>> >> >> with:
>> >> >>
>> >> >>     T opIndexAssign(V value, int index) { ... }
>> >> >
>> >> >Why swap the arguments over?  To confuse people?  Or does it somehow
>> >> >simplify the extension to multi-indexes?
>> >>
>> >> T opIndexAssign(V value, int index1, int index2, int index3, ...) {}
>> >
>> >Maybe it should be:
>> >
>> >T opIndexAssign(int index1, int index2, int index3, ... , V value) {}
>>
>>
>> Depending on the future of multi-dim arrays, is there a need for:
>>
>> T opIndexAssign(Value V, int i1, int i2, int i3); // X3
>> T opIndexAssign(Value V, int i1, int i2); // X2
>> T opIndexAssign(Value V, int i1); // X1
>>
>> .. on the same array?  I.e. the X1 model would return a two-dim slice of the
>> original?  If so, maybe Value should be first for symmetry.
>
>Good point.
>
>Presumably the higher order overloads are slices, and the lowest is for accessing
>the actual cell/element?

If you mean X3 is highest, then yes.

Kevin
June 15, 2004
Re: array assignment overloading change to opIndexAssign()
In article <camr4m$1tfl$1@digitaldaemon.com>, Norbert Nemec says...
>
>Kevin Bealer wrote:
>
>> Depending on the future of multi-dim arrays, is there a need for:
>> 
>> T opIndexAssign(Value V, int i1, int i2, int i3); // X3
>> T opIndexAssign(Value V, int i1, int i2); // X2
>> T opIndexAssign(Value V, int i1); // X1
>> 
>> .. on the same array?  I.e. the X1 model would return a two-dim slice of
>> the
>> original?  If so, maybe Value should be first for symmetry.
>
>That depends very much on what kind of array you implement. The
>language-supported arrays that I'm proposing in my draft allow indexing and
>slicing only for exactly the same dimensionality as the array. For indexing
>only certain dimensions, you will have to do something like
>
>        int[3,3,3] A = ...;
>        int[3,3] B = A[1,,];
>
>So for these arrays, the answer to your question would be "no". Anyhow: the
>overloaded opIndexAssign is meant to be flexible to be used in all kinds of
>data-structures. Who knows when somebody finds a use for different numbers
>of indices in some data-structure?

If you don't like them or can't support them, don't implement them, and the
corresponding slicing operation becomes forbidden.  This is analagous to current
language definitions, where you opt to support comparisons by defining opCmp,
etc.

In my proposed syntax, I was assuming that a 5x10x20 array would not produce a
3x3 array no matter how you slice it.  You either slice out a 10x20 or a 5x10,
or a 5 or a 20, depending on how many layers you peel off and whether it is a
column-first or row-first implementation.  Column versus row ordering would be
determined by the implementor or the language and would determine whether you
get the first N indices or the last N when you slice and dice.

Kevin
June 16, 2004
Re: array assignment overloading change to opIndexAssign()
"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message
news:cans7t$fl1$1@digitaldaemon.com...
> In article <camr4m$1tfl$1@digitaldaemon.com>, Norbert Nemec says...
> >
> >Kevin Bealer wrote:
> >
> >> Depending on the future of multi-dim arrays, is there a need for:
> >>
> >> T opIndexAssign(Value V, int i1, int i2, int i3); // X3
> >> T opIndexAssign(Value V, int i1, int i2); // X2
> >> T opIndexAssign(Value V, int i1); // X1
> >>
> >> .. on the same array?  I.e. the X1 model would return a two-dim slice
of
> >> the
> >> original?  If so, maybe Value should be first for symmetry.
> >
> >That depends very much on what kind of array you implement. The
> >language-supported arrays that I'm proposing in my draft allow indexing
and
> >slicing only for exactly the same dimensionality as the array. For
indexing
> >only certain dimensions, you will have to do something like
> >
> >        int[3,3,3] A = ...;
> >        int[3,3] B = A[1,,];
> >
> >So for these arrays, the answer to your question would be "no". Anyhow:
the
> >overloaded opIndexAssign is meant to be flexible to be used in all kinds
of
> >data-structures. Who knows when somebody finds a use for different
numbers
> >of indices in some data-structure?
>
> If you don't like them or can't support them, don't implement them, and
the
> corresponding slicing operation becomes forbidden.  This is analagous to
current
> language definitions, where you opt to support comparisons by defining
opCmp,

Not true! opCmp is not an option, when you write a class you get it (want
it or not).

Couldn't resist to mention opCmp(and opEquals)  topic again :)

> etc.
>
> In my proposed syntax, I was assuming that a 5x10x20 array would not
produce a
> 3x3 array no matter how you slice it.  You either slice out a 10x20 or a
5x10,
> or a 5 or a 20, depending on how many layers you peel off and whether it
is a
> column-first or row-first implementation.  Column versus row ordering
would be
> determined by the implementor or the language and would determine whether
you
> get the first N indices or the last N when you slice and dice.
>
> Kevin
>
>
>
June 16, 2004
Re: array assignment overloading change to opIndexAssign()
Kevin Bealer wrote:

> In my proposed syntax, I was assuming that a 5x10x20 array would not
> produce a
> 3x3 array no matter how you slice it.  You either slice out a 10x20 or a
> 5x10, or a 5 or a 20, depending on how many layers you peel off and
> whether it is a
> column-first or row-first implementation.  Column versus row ordering
> would be determined by the implementor or the language and would determine
> whether you get the first N indices or the last N when you slice and dice.

My multidim-Array proposal is more flexible. You can mix slicing and partial
indexing in one expression:

       int[[4]] A = new int[5,10,20,2];
       int[[3]] B = A[2,1..7:2,5..6,];

Here, the first dimension is indexed, to the resulting array has one
dimension less. The second and the third dimension are both sliced. The
second one with stride 2, so it leaves three entries (1,3 and 5) the second
one leaves range 1. The last dimension is left untouched. The result would
be an 3x1x2 array.

Row versus column ordering is handled fully transparently to the programmer.
The default is Fortran-style alignment, but you can just as well create a
C-style array in memory. The user of an array does not need to think about
the memory layout.

For more details, see
       http://homepages.uni-regensburg.de/~nen10015/documents/D-multidimarray.html

Ciao,
Nobbi
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home