Why is there no gslice_array<T>::operator[](size_t) member function?
( This conclusion is based on http://www-leland.stanford.edu/
~iburrel/cpp/ wp-draft/ lib-numerics.html#lib.template.gslice.array ).
Such an operator would seem to be useful for matrix multiplication of
subsets of a matrix or transposes of a matrix.  Examples are
Strassen's matrix multiplication algorithm[Sara Baase, _Computer
Algorithms_ 2nd ed.,Addison-Wesley(1991) p. 266 ] and calculation of
Bicubic surfaces[ Foley, et.al.,_Introduction to Computer Graphics_,
Addison-Wesley(1994) p. 254].

Just as there's a vector<T>::iterator class, why is there not a
gslice_array<T>::iterator class? (In the code examples below, {...}
signifies some implementation code.)  In order to reflect the "array of
arrays" semantics of normal multi-dimensional arrays, this iterator
class would have to be a little different than the normal iterator.
For example, the operator* might be declared:

   gslice_array<T> gslice_array<T>::iterator::operator*(){...}

instead of:

   T& gslice_array<T>::iterator::operator*(){...}

where the result gslice_array rank = source gslice_array rank-1.  Rank
of a gslice_array would be defined in terms of the gslice used to
create it.  The rank would be reported by a new member function:

   size_t gslice_array::rank(){...}

For example, given the following code:

    const size_t n0=8;
    const size_t n1=8;
    valarray<float> fvec(n0*n1);
    const size_t start=0;
    const size_t rank=2;
    valarray<size_t> length(rank);
    length[0]=n0;
    length[1]=n1;
    valarray<size_t> stride(rank);
    stride[0]=n1;
    stride[1]=1;
    gslice gs(start,length,stride);
    gslice_array fmat=fvec[gs];

then the following would be true:

    fmat.rank() == length.length()

Likewise, the operator:

   gslice_array<T> gslice_array<T>::iterator::operator[](size_t);

would have the same requirement on the rank of source and result
gslice_arrays.

To return a T&, another operator would have to be
provided.  Operator()(size_t) might serve this purpose as follows:

   T& gslice_array<T>::iterator::operator()(size_t);

I am currently working on a multi-dimensional array class with similar
capabilities, and of course I'm interested in what disadvantages there
might be in providing these extra capabilities.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

>>>>> "LE" == Larry J Evans <evansl@cs.tamu.edu> writes:

LE> Why is there no gslice_array<T>::operator[](size_t) member function?
LE> ( This conclusion is based on http://www-leland.stanford.edu/
LE> ~iburrel/cpp/ wp-draft/ lib-numerics.html#lib.template.gslice.array ).
LE> Such an operator would seem to be useful for matrix multiplication of
LE> subsets of a matrix or transposes of a matrix.

Perhaps because it turns out to be an extremely expensive operation
in practice?

LE> Examples are
LE> Strassen's matrix multiplication algorithm[Sara Baase, _Computer
LE> Algorithms_ 2nd ed.,Addison-Wesley(1991) p. 266 ] and calculation of
LE> Bicubic surfaces[ Foley, et.al.,_Introduction to Computer Graphics_,
LE> Addison-Wesley(1994) p. 254].

Both of these problems can be handled with ``simple slices''
(gslices of order one, if you will). In fact most (all?) matrix
operations only require slices, not general slices.

[...]
LE> I am currently working on a multi-dimensional array class with similar
LE> capabilities, and of course I'm interested in what disadvantages there
LE> might be in providing these extra capabilities.

A general observation here. The `raison d'etre' for valarrays is
efficiency, in particular with regards to the kind of operations
that occurs in scientific computing. If efficiency were of no
concern, there would be no need for an array class distinct from
std::vector<T>, IMO. Now, if you want a multidimensional array
type and you want it to support operations that are compiled into
efficient code, it helps a _lot_ to know the number of dimensions
at compile time. An interface that makes the dimensionality a run-
time quantity is thus not recommended.

Your comments in fact boil down to the --- IMO very pertinent ---
observation that a gslice_array<T> is _not_ an array; it is but a
``mask'' that is fitted to a 1D array to permit assignments that
show the pattern of assignment to a multidimensional subset of a
multidimensional array. The multidimensional illusion does not
persist at all.

Because of these shortcomings, I have proposed that `general slices'
be dropped from standard valarrays. What I (and I suspect many others
like me) really would like is true multidimensional valarrays. This
can be done, but the time left to come up with tested specifications
is probably too short for that.

 Daveed
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

(This article is cross-posted to sci.math.num-analysis where some
 potential valarray users may be watching; followups are to comp.std.c++)

>>>>> "DV" == David Vandevoorde <vandevod@cs.rpi.edu> writes:
[...]
DV> Because of these shortcomings, I have proposed that `general
DV> slices' be dropped from standard valarrays. What I (and I suspect
DV> many others like me) really would like is true multidimensional
DV> valarrays. This can be done, but the time left to come up with
DV> tested specifications is probably too short for that.

While I am at it, I also submitted a somewhat more extensive valarray
modification proposal for the Stockholm ISO/ANSI meeting. It allows a
C++ programming technique often called `expression templates' to be
used when implementing valarrays, without hindering other
implementation techniques.

If you'd like to review this proposal for consistency, typos,
grammatical mistakes, etc. you can pick it up at:

    ftp://ftp.cs.rpi.edu/pub/vandevod/Valarray/Documents/stockholm.txt

Any sort of comments is welcome, but note that requests for significant
extensions are unlikely to be addressed in the first C++ standard.

 Daveed


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]