Loading ...
Sorry, an error occurred while loading the content.

Re: [boost] Boost.Numeric: multi_array spec/docs

Expand Messages
  • Toon Knapen
    ... Isn t that confusing. And mathematically there s a hugh difference between operations where the result has the same dimension or a lower dimension. Why
    Message 1 of 24 , Apr 1, 2001
    • 0 Attachment
      >
      > I'm not sure that making a distinction between slices and subarrays is
      > beneficial. For example, the operator[] can end up returning a slice *or*
      > a subarray depending on the arguments... I think it would be easier to
      > refer to both as just subarrays.
      Isn't that confusing. And mathematically there's a hugh difference
      between operations where the result has the same dimension or
      a lower dimension. Why would we make they be identical then
      in C++ syntax ?


      >
      > You're right, some definitions are needed.
      >
      > toon> Why is the index signed ? There were arguments about fortran or
      > toon> C-style but I would expect the sign-type to be generall size_t
      >
      > The multi-array currently allows for arbitrary index-ranges, [-10,-5)
      > would be ok, and indices into this range would need to be signed.

      I was just wondering if anyone really needs negative indices. If not,
      indices get often compared to e.g. the size of a vector which is
      size_t and thus generates a warning comparing signed and unsigned
      integers.


      t
    • Jeremy Siek
      On Sun, 1 Apr 2001, Toon Knapen wrote: toon Isn t that confusing. And mathematically there s a hugh difference toon between operations where the result has
      Message 2 of 24 , Apr 1, 2001
      • 0 Attachment
        On Sun, 1 Apr 2001, Toon Knapen wrote:
        toon> Isn't that confusing. And mathematically there's a hugh difference
        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][2][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.

        toon> I was just wondering if anyone really needs negative indices. If not,
        toon> indices get often compared to e.g. the size of a vector which is
        toon> size_t and thus generates a warning comparing signed and unsigned
        toon> integers.

        That is certainly a good concern. I'd like to keep this as an open
        question.

        Cheers,
        Jeremy

        ----------------------------------------------------------------------
        Jeremy Siek www: http://www.lsc.nd.edu/~jsiek/
        Ph.D. Candidate email: jsiek@...
        Univ. of Notre Dame work phone: (219) 631-3906
        ----------------------------------------------------------------------
      • Larry Evans
        ... So, just to be sure I understand, the following expression: A[3
        Message 3 of 24 , Apr 1, 2001
        • 0 Attachment
          Jeremy Siek wrote:

          > On Sun, 1 Apr 2001, Toon Knapen wrote:
          > toon> Isn't that confusing. And mathematically there's a hugh difference
          > 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][2][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]
          [all][all][all]

          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].
        • Serge Barral
          ... Actually, the result of A[3
          Message 4 of 24 , Apr 2, 2001
          • 0 Attachment
            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
            > difference
            > > 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][2][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]
            > [all][all][all]
            >
            > 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.

            Serge
          • Jeremy Siek
            On Sun, 1 Apr 2001, Larry Evans wrote: jcampb So, just to be sure I understand, the following expression: jcampb jcampb A[3
            Message 5 of 24 , Apr 2, 2001
            • 0 Attachment
              On Sun, 1 Apr 2001, Larry Evans wrote:
              jcampb> So, just to be sure I understand, the following expression:
              jcampb>
              jcampb> A[3 <= stride(2) < 7][all][0 <= stride(1) < 10]
              jcampb> [all][all][all]
              jcampb>
              jcampb> would be a 3 dimensional array. This means that you could
              jcampb> have an infinite number of [sliceExpr] operators strung together,
              jcampb> where sliceExpr is either all or something like [3<=stride(1)<7].

              Well, not really infinite ;) The number of []'s has to be the same as the
              number of dimensions in the array (unless you use the .all() method).
              However, there is no hard-coded limit on the number of dimensions.

              Cheers,
              Jeremy

              ----------------------------------------------------------------------
              Jeremy Siek www: http://www.lsc.nd.edu/~jsiek/
              Ph.D. Candidate email: jsiek@...
              Univ. of Notre Dame work phone: (219) 631-3906
              ----------------------------------------------------------------------
            • Jeremy Siek
              On Mon, 2 Apr 2001, Serge Barral wrote: sbarra Actually, the result of A[3 would be a 3 dimensional
              Message 6 of 24 , Apr 2, 2001
              • 0 Attachment
                On Mon, 2 Apr 2001, Serge Barral wrote:
                sbarra> Actually, the result of A[3 <= stride(2) < 7][all][0 <= stride(1) < 10]
                sbarra> would be a 3 dimensional subarray.
                sbarra> The current proposal suggests that subarrays will support indexing, but how
                sbarra> about slicing? Is it really often necessary in practice?

                I think it is important to keep subarray's as close to array's as
                possible... it is conceptually simpler for the user that way.

                sbarra> I guess some confusion comes from the name "subarray" being different from
                sbarra> "array". As I understand it, the distinction is not based on mathematical
                sbarra> considerations, but is a distinction in the types that makes the
                sbarra> implementation more efficient (a subarray is only a "view" of a multi_array
                sbarra> and thus avoids the creation of a temporary multi_array).

                Right. The actual class we were going to use for the subarray type is
                going to be named something like multi_array_view or
                multi_array_reference.

                sbarra> But if my assumption above is correct, I don't understand how the result of
                sbarra> indirect slicing and the result of slicing with Range objects can be of the
                sbarra> same type, since these are two different kind of views.

                I don't either ;) They will need to be different types. I haven't figured
                out how to express the different types yet (in terms of the interface
                presented to the user).

                Cheers,
                Jeremy

                ----------------------------------------------------------------------
                Jeremy Siek www: http://www.lsc.nd.edu/~jsiek/
                Ph.D. Candidate email: jsiek@...
                Univ. of Notre Dame work phone: (219) 631-3906
                ----------------------------------------------------------------------
              • Serge Barral
                ... I see. But then what s the type of a subarray of subarray? ... Blitz solves the problem by not documenting subarray types :-). The user just knows that
                Message 7 of 24 , Apr 2, 2001
                • 0 Attachment
                  On Mon, 02 Apr 2001 17:26:06 Jeremy Siek wrote:
                  > On Mon, 2 Apr 2001, Serge Barral wrote:
                  > sbarra> Actually, the result of A[3 <= stride(2) < 7][all][0 <= stride(1)
                  > < 10]
                  > sbarra> would be a 3 dimensional subarray.
                  > sbarra> The current proposal suggests that subarrays will support
                  > indexing, but how
                  > sbarra> about slicing? Is it really often necessary in practice?
                  >
                  > I think it is important to keep subarray's as close to array's as
                  > possible... it is conceptually simpler for the user that way.
                  >

                  I see. But then what's the type of a subarray of subarray?

                  > [...]
                  > sbarra> But if my assumption above is correct, I don't understand how the
                  > result of
                  > sbarra> indirect slicing and the result of slicing with Range objects can
                  > be of the
                  > sbarra> same type, since these are two different kind of views.
                  >
                  > I don't either ;) They will need to be different types. I haven't figured
                  > out how to express the different types yet (in terms of the interface
                  > presented to the user).
                  >

                  Blitz solves the problem by not documenting subarray types :-). The user
                  just knows that they behave like and are convertible to normal arrays. It
                  makes sense in the case of Blitz (and of other expression template
                  libraries) since anyway the result of most operations involving arrays is
                  not strictly of type array. Note that it also solves the problem mentionned
                  above (subarray of subarray)...
                  One problem I can see with this approach is that the user cannot store
                  subarrays efficiently (a conversion to array is required). Are there other
                  good reasons for documenting the exact type of subarrays?

                  Serge
                • Toon Knapen
                  ... Would the interface of an indirect subarray not be identical to a strided subarray ? t
                  Message 8 of 24 , Apr 2, 2001
                  • 0 Attachment
                    Jeremy Siek wrote:
                    > sbarra> But if my assumption above is correct, I don't understand how the result of
                    > sbarra> indirect slicing and the result of slicing with Range objects can be of the
                    > sbarra> same type, since these are two different kind of views.
                    >
                    > I don't either ;) They will need to be different types. I haven't figured
                    > out how to express the different types yet (in terms of the interface
                    > presented to the user).

                    Would the interface of an indirect subarray not be identical to a
                    strided subarray ?

                    t
                  • boost
                    Salut, [...] ... Shouldn t that just be a subarray? Best wishes, Peter
                    Message 9 of 24 , Apr 2, 2001
                    • 0 Attachment
                      Salut,

                      [...]
                      >
                      > I see. But then what's the type of a subarray of subarray?
                      Shouldn't that just be a subarray?

                      Best wishes,
                      Peter
                    • Larry Evans
                      ... One example of subarray slicing is the recursive strassen[1] matrix multiplication. However, I ve also heard that this is NOT used in practice because it s
                      Message 10 of 24 , Apr 2, 2001
                      • 0 Attachment
                        Serge Barral wrote:

                        > On Mon, 02 Apr 2001 17:26:06 Jeremy Siek wrote:
                        > > On Mon, 2 Apr 2001, Serge Barral wrote:
                        > > sbarra> Actually, the result of A[3 <= stride(2) < 7][all][0 <= stride(1)
                        > > < 10]
                        > > sbarra> would be a 3 dimensional subarray.
                        > > sbarra> The current proposal suggests that subarrays will support
                        > > indexing, but how
                        > > sbarra> about slicing? Is it really often necessary in practice?

                        One example of subarray slicing is the recursive strassen[1] matrix multiplication.
                        However, I've also heard that this is NOT used in practice because it's slow
                        (I guess because of the recursion).

                        >
                        > >
                        > > I think it is important to keep subarray's as close to array's as
                        > > possible... it is conceptually simpler for the user that way.
                        > >
                        >
                        > I see. But then what's the type of a subarray of subarray?
                        >
                        > > [...]
                        > > sbarra> But if my assumption above is correct, I don't understand how the
                        > > result of
                        > > sbarra> indirect slicing and the result of slicing with Range objects can
                        > > be of the
                        > > sbarra> same type, since these are two different kind of views.
                        > >
                        > > I don't either ;) They will need to be different types. I haven't figured
                        > > out how to express the different types yet (in terms of the interface
                        > > presented to the user).
                        > >

                        I'm unsure what indirect slicing is. Is it the use of an vector of indices to create
                        a subarray, as in the following?

                        int indices0[] = {1,5,6,10};
                        int indices1[] = {5,4,6};
                        int xshape[] = {10,6};
                        array<double,2> x(xshape);
                        int yshape[] = {4,3};
                        array<double,2> y(yshape);
                        y = x[indices0][indices1];

                        ====================== references ==============
                        [1] Strassen, volker, "Gaussian elimination is not optimal"
                        _Numerische Mathematik_, vol. 13, pp. 354-356, 1969.
                      • Jeremy Siek
                        On Mon, 2 Apr 2001, Larry Evans wrote: jcampb jcampb One example of subarray slicing is the recursive strassen[1] matrix multiplication. jcampb However,
                        Message 11 of 24 , Apr 2, 2001
                        • 0 Attachment
                          On Mon, 2 Apr 2001, Larry Evans wrote:
                          jcampb>
                          jcampb> One example of subarray slicing is the recursive strassen[1] matrix multiplication.
                          jcampb> However, I've also heard that this is NOT used in practice because it's slow
                          jcampb> (I guess because of the recursion).

                          There have been a few cases where people have used strassen. At one point
                          Cray used it in there implementation the BLAS gdemm to get a better
                          linpack benchmark result. One trouble with strassen is that it is only
                          better than the usual algorithm when the matrices get large. The typical
                          approach is to do strassen-style recursion until the submatrices are small
                          enough, and then use the normal algorithm.

                          jcampb> I'm unsure what indirect slicing is. Is it the use of an vector of indices to create
                          jcampb> a subarray, as in the following?
                          jcampb>
                          jcampb> int indices0[] = {1,5,6,10};
                          jcampb> int indices1[] = {5,4,6};
                          jcampb> int xshape[] = {10,6};
                          jcampb> array<double,2> x(xshape);
                          jcampb> int yshape[] = {4,3};
                          jcampb> array<double,2> y(yshape);
                          jcampb> y = x[indices0][indices1];

                          Yep, that's it. Also, see the example in the multi_array docs Ron and I
                          are working on:

                          http://www.lsc.nd.edu/~jsiek/tlc/multi_array/libs/numeric/doc/multi_array.html


                          ----------------------------------------------------------------------
                          Jeremy Siek www: http://www.lsc.nd.edu/~jsiek/
                          Ph.D. Candidate email: jsiek@...
                          Univ. of Notre Dame work phone: (219) 631-3906
                          ----------------------------------------------------------------------
                        • Serge Barral
                          ... I naively thought that since a first level subarray contains a reference to a multi_array, a subarray of subarray should contain a reference to a subarray
                          Message 12 of 24 , Apr 3, 2001
                          • 0 Attachment
                            On Mon, 02 Apr 2001 22:17:37 Peter Schmitteckert wrote:
                            > [...]
                            > >
                            > > I see. But then what's the type of a subarray of subarray?
                            > Shouldn't that just be a subarray?

                            I naively thought that since a first level subarray contains a reference to
                            a multi_array, a subarray of subarray should contain a reference to a
                            subarray and would thus be of a different type (unless run-time
                            polymorphism is used, but this is probably not a recommended solution for
                            numeric arrays).

                            I guess your idea is that a subarray of subarray could reference only the
                            top-level multi_array and compute the topology of the slice with respect to
                            this top-level array. I must say I overlooked this possibility.

                            Serge
                          Your message has been successfully submitted and would be delivered to recipients shortly.