From: Serge Barral (sbarral_at_[hidden])
Date: 2001-04-02 05:25:58
On Sun, 01 Apr 2001 23:20:46 Larry Evans wrote:
> Jeremy Siek wrote:
> > On Sun, 1 Apr 2001, Toon Knapen wrote:
> > toon> Isn't that confusing. And mathematically there's a hugh
> > toon> between operations where the result has the same dimension or
> > toon> a lower dimension. Why would we make they be identical then
> > toon> in C++ syntax ?
> > Well, its not identical syntax, but similar:
> > assume A is 3 dimensional
> > A[3 <= stride(1) < 7][0 <= stride(1) < 10]
> > gives you a 2 dimensional array
> > A[3 <= stride(2) < 7][all][0 <= stride(1) < 10]
> > gives you a 3 dimensional array
> > At least to me, the above syntax is quite clear.
> > Now, according to Blitz terminology, the 1st thing is a slice
> > and the 2nd thing is a subarray. However, in the docs for
> > operator I'd rather just say that the thing returned is
> > a subarray.
> So, just to be sure I understand, the following expression:
> A[3 <= stride(2) < 7][all][0 <= stride(1) < 10]
> would be a 3 dimensional array. This means that you could
> have an infinite number of [sliceExpr] operators strung together,
> where sliceExpr is either all or something like [3<=stride(1)<7].
Actually, the result of A[3 <= stride(2) < 7][all][0 <= stride(1) < 10]
would be a 3 dimensional subarray.
The current proposal suggests that subarrays will support indexing, but how
about slicing? Is it really often necessary in practice?
I guess some confusion comes from the name "subarray" being different from
"array". As I understand it, the distinction is not based on mathematical
considerations, but is a distinction in the types that makes the
implementation more efficient (a subarray is only a "view" of a multi_array
and thus avoids the creation of a temporary multi_array).
But if my assumption above is correct, I don't understand how the result of
indirect slicing and the result of slicing with Range objects can be of the
same type, since these are two different kind of views.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk