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

row_major_tag [was: Suggestion for ublas]

Expand Messages
  • Toon Knapen
    ... Thanks again for pointing this out so clear. What I now wonder about is : are nt column_major and column_major_tag redundant ? Both are types and denote
    Message 1 of 7 , May 2, 2003
    • 0 Attachment
      On Monday 28 April 2003 18:08, you wrote:
      >
      > // in functional.hpp:
      > struct row_major {
      > // ...
      > typedef row_major_tag orientation_category;
      > // ...
      > };
      > struct column_major {
      > // ...
      > typedef column_major_tag orientation_category;
      > // ...
      > };
      >
      > // in config.hpp:
      > struct row_major_tag {};
      > struct column_major_tag {};

      Thanks again for pointing this out so clear.
      What I now wonder about is : are'nt column_major and column_major_tag redundant ?
      Both are types and denote the same thing. The only diff is that *_tag is an empty struct
      whereas the others do real work. Is'nt the idea of tag's (as in iterator_tag's) of having an
      _object_ of a type to specify template types via the argument list ?
    • Kresimir Fresl
      ... Yes, and just for this reason it is good to have both. Construction of an empty object is less expensive. So, if you have to overload a template function,
      Message 2 of 7 , May 5, 2003
      • 0 Attachment
        Toon Knapen wrote:

        >> // in functional.hpp:
        >> struct row_major {
        >> // ...
        >> typedef row_major_tag orientation_category;
        >> // ...
        >> };
        >> struct column_major {
        >> // ...
        >> typedef column_major_tag orientation_category;
        >> // ...
        >> };
        >>
        >> // in config.hpp:
        >> struct row_major_tag {};
        >> struct column_major_tag {};

        > Thanks again for pointing this out so clear.
        > What I now wonder about is : are'nt column_major and column_major_tag redundant ?
        > Both are types and denote the same thing. The only diff is that *_tag is an empty struct
        > whereas the others do real work. Is'nt the idea of tag's (as in iterator_tag's) of having an
        > _object_ of a type to specify template types via the argument list ?

        Yes, and just for this reason it is good to have both.
        Construction of an empty object is less expensive.
        So, if you have to overload a template function, that is,
        to dispatch work to overloaded template functions,
        it is useful to have a cheap way to create an object:

        template <typename M>
        void f (M& m) {
        f_impl (m, M::orientation_category());
        }

        template <typename M>
        void f_impl (M& m, row_major_tag) {
        func_for_row_major_matrix (m);
        }
        template <typename M>
        void f_impl (M& m, column_major_tag) {
        func_for_column_major_matrix (m);
        }

        f.
      • Toon Knapen
        ... But struct row_major is also empty, i.e. it has no member variables, nor virtual functions and thus a zero memory footprint ? toon
        Message 3 of 7 , May 5, 2003
        • 0 Attachment
          On Monday 05 May 2003 11:48, Kresimir Fresl wrote:
          > Yes, and just for this reason it is good to have both.
          > Construction of an empty object is less expensive.
          But 'struct row_major' is also empty, i.e. it has no member
          variables, nor virtual functions and thus a zero memory
          footprint ?

          toon
        • Kresimir Fresl
          ... I must admit that I didn t look into the definition of row_major. But even if you are right (and you are ;o), can you be sure that it will be empty in the
          Message 4 of 7 , May 5, 2003
          • 0 Attachment
            Toon Knapen wrote:

            > On Monday 05 May 2003 11:48, Kresimir Fresl wrote:
            >
            >>Yes, and just for this reason it is good to have both.
            >> Construction of an empty object is less expensive.
            >
            > But 'struct row_major' is also empty, i.e. it has no member
            > variables, nor virtual functions and thus a zero memory
            > footprint ?

            I must admit that I didn't look into the definition of row_major.
            But even if you are right (and you are ;o), can you be sure
            that it will be empty in the next version of ublas?

            Also, it's good to have a uniform way to differentiate
            tags from other classes.

            f.
          • Toon Knapen
            ... good point ... true. OK, I m in peace with the implementation as is (and learned a few things on the way again) so I rest my case. toon
            Message 5 of 7 , May 5, 2003
            • 0 Attachment
              On Monday 05 May 2003 14:02, Kresimir Fresl wrote:
              > Toon Knapen wrote:
              >
              > > On Monday 05 May 2003 11:48, Kresimir Fresl wrote:
              > >
              > >>Yes, and just for this reason it is good to have both.
              > >> Construction of an empty object is less expensive.
              > >
              > > But 'struct row_major' is also empty, i.e. it has no member
              > > variables, nor virtual functions and thus a zero memory
              > > footprint ?
              >
              > I must admit that I didn't look into the definition of row_major.
              > But even if you are right (and you are ;o), can you be sure
              > that it will be empty in the next version of ublas?
              good point

              > Also, it's good to have a uniform way to differentiate
              > tags from other classes.
              true.

              OK, I'm in peace with the implementation as is (and learned a few
              things on the way again) so I rest my case.

              toon
            • jhr.walter@t-online.de
              Hi Toon, hi Kresimir, you both made good points. My main rationale not to change things is that we have three storage categories currently (row major, column
              Message 6 of 7 , May 5, 2003
              • 0 Attachment
                Hi Toon, hi Kresimir,

                you both made good points. My main rationale not to change things is that we
                have three storage categories currently (row major, column major and
                unknown), but only two policies(?) (row major and column major). I still
                believe that's a valid distinction (although one probably could change
                that).

                Thanks,

                Joerg

                ----- Original Message -----
                From: "Toon Knapen" <toon.knapen@...>
                To: <ublas-dev@yahoogroups.com>
                Sent: Monday, May 05, 2003 2:57 PM
                Subject: Re: [ublas-dev] row_major_tag [was: Suggestion for ublas]


                > On Monday 05 May 2003 14:02, Kresimir Fresl wrote:
                > > Toon Knapen wrote:
                > >
                > > > On Monday 05 May 2003 11:48, Kresimir Fresl wrote:
                > > >
                > > >>Yes, and just for this reason it is good to have both.
                > > >> Construction of an empty object is less expensive.
                > > >
                > > > But 'struct row_major' is also empty, i.e. it has no member
                > > > variables, nor virtual functions and thus a zero memory
                > > > footprint ?
                > >
                > > I must admit that I didn't look into the definition of row_major.
                > > But even if you are right (and you are ;o), can you be sure
                > > that it will be empty in the next version of ublas?
                > good point
                >
                > > Also, it's good to have a uniform way to differentiate
                > > tags from other classes.
                > true.
                >
                > OK, I'm in peace with the implementation as is (and learned a few
                > things on the way again) so I rest my case.
                >
                > toon
                >
                >
                >
                > To unsubscribe from this group, send an email to:
                > ublas-dev-unsubscribe@yahoogroups.com
                >
                >
                >
                > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                >
                >
              • Toon Knapen
                ... also a good point !
                Message 7 of 7 , May 6, 2003
                • 0 Attachment
                  On Tuesday 06 May 2003 07:57, jhr.walter@... wrote:
                  > Hi Toon, hi Kresimir,
                  >
                  > you both made good points. My main rationale not to change things is that we
                  > have three storage categories currently (row major, column major and
                  > unknown), but only two policies(?) (row major and column major). I still
                  > believe that's a valid distinction

                  also a good point !
                Your message has been successfully submitted and would be delivered to recipients shortly.