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

Direction of ublas development: array_adaptor, bindings, ,multi_array, documentation

Expand Messages
  • Toon Knapen
    Dear All, I have spent a large part of this past week evaluating and experimenting with the ublas and bindings library with a view to employing them in a large
    Message 1 of 2 , Dec 1, 2004
      Dear All,

      I have spent a large part of this past week evaluating and experimenting
      with the ublas and bindings library with a view to employing them in a
      large coding project in the quasi real-time image processing domain. I
      have several questions for the ublas development community and would
      also like to pass on some comments based on my evaluation.

      1. What is the status of the array_adaptor class within the ublas library?
      This class is currently undocumented, however, provides a very important
      role in providing a method to view data that is not owned by the
      library. Can developers write applications using this class to access
      the power of ublas and be confident that it is not suddenly going to
      disappear in future releases? Is the intention to eventually document
      the class and make it a first class citizen in the library? In the image
      processing field the ability to manipulate the image data (which may
      have been stored by a 3rd party image acquisition library, for example)
      using ublas is very attractive. However, if I had to copy these large
      image arrays into a ublas matrix that would be very inefficient and may
      prevent me using the ublas library.

      2. Will ublas continue to work with the bindings library (and in
      particular the ATLAS bindings) in future releases?
      There has been quite a lot of discussion in the mailing list about
      protecting access to class members and slimming down the public
      interface. It appears that as of Boost v1.32 (on MSVC v7.1 platform)
      this has already started to happen. The ATLAS bindings require access to
      the ublas::vector.expression() and ublas::matrix.expression() member. In
      the latest release these functions have been made private resulting in
      compiler errors. The simplest workaround I have found is to #define
      BOOST_UBLAS_NESTED_CLASS_DR45 in my application before including the
      ublas headers as this ensures that the expression() function is public.

      For example,

      // -----------------------------------
      // Nasty workaround for making the expression() member public
      #define BOOST_UBLAS_NESTED_CLASS_DR45
      // -----------------------------------

      // Boost numeric uBlas library
      #include <boost/numeric/ublas/vector.hpp>
      #include <boost/numeric/ublas/vector_proxy.hpp>
      #include <boost/numeric/ublas/matrix.hpp>
      #include <boost/numeric/ublas/matrix_proxy.hpp>
      #include <boost/numeric/ublas/io.hpp>

      // Boost numeric bindings library: Storage traits for std::vector and
      std::valarray
      #include <boost/numeric/bindings/traits/std_vector.hpp>
      #include <boost/numeric/bindings/traits/std_valarray.hpp>

      // Boost numeric bindings library: Storage traits for ublas::vector and
      ublas::matrix families
      #include <boost/numeric/bindings/traits/ublas_vector.hpp>
      #include <boost/numeric/bindings/traits/ublas_matrix.hpp>

      // Boost numeric bindings library: ATLAS linear algebra library bindings
      #include <boost/numeric/bindings/atlas/cblas.hpp>

      namespace ublas = boost::numeric::ublas;
      namespace atlas = boost::numeric::bindings::atlas;

      int main( int argc, char **argv )
      {
      // ublas:matrix
      ublas::matrix<double> um (5, 5);
      // Initialise
      double c = 0;
      for (unsigned uiRow = 0; uiRow < um.size1(); uiRow++)
      for (unsigned uiCol = 0; uiCol < um.size2(); uiCol++)
      um(uiRow,uiCol) = c++;
      // Dump
      std::cout << std::endl << "um = " << um << std::endl;

      // Matrix row vector
      ublas::matrix_row<ublas::matrix<double> > umr (um, 1);
      // Dump
      std::cout << std::endl << "umr = " << umr << std::endl;
      // Call ATLAS
      std::cout << "L2-norm = " << atlas::nrm2 (umr) << std::endl;

      return 0;
      }

      <begin personal rant>
      Whilst I am sure that many of the implementors of the ublas library
      focus on the "theoretical correctness" of the library and its
      interfaces, much of the power of the library stems from the fact that it
      can be used to manipulate numerical vectors and matrices efficiently. In
      this case, efficiently relates not just to the the time taken to develop
      readable and correct applications, but also to the runtime. In the
      latter case, the ability to access the optimised linear algebra provided
      by ATLAS, CBLAS, CLAPACK, etc, and do so through a simple and clean
      interface, significantly adds to the value of the ublas library. I am
      therefore a concerned that the push to slim the public interface to the
      library in future releases may prevent application developers from
      accessing its real benefits, as demonstrated by the bindings library.
      Those people driving the design and implementation of the ublas library
      have unquestionably put an awful lot of effort into the development of
      this library (and should be very proud of the result) and I feel that it
      would be a terrible shame to introduce barriers to its adoption by
      application developers. In many ways, it seems that the forces
      associated with formal generic programming and the forces associated
      with practical application development often pull in opposite directions
      when looking at the fine detail.
      <end personal rant>

      3. What is the feeling in the community regarding interoperability
      between ublas::vector, ublas::matrix and boost::multi_array?
      This is a topic that has been addressed in some posts in the mailing
      list, both in relation to adaptors and bindings, but I am unclear of the
      current situation. The main difficulty referred to in the mailing list
      seems to relate to the fact that although the storage_order could be
      defined in the constructor, it was not possible to query this property
      later. It seems, according to the documentation at least, that
      multi_array now supports querying of the storage order through the
      storage_order() member. Personally, I seems completely logically to
      provide "array adaptors" for multi_array objects, but I cannot comment
      on its feasibility. Following my comments in section 2, it will not
      surprise you to learn that I also strongly encourage support for
      multi_array in the bindings library.

      4. As a newcomer to the libraries I have to admit that I found it a very
      steep learning curve as the documentation is definitely NOT end-user
      orientated, and I often had to search the mailing list to find a more
      human readable answer to my queries. In many instances I also had to
      refer to the source code to research undocumented features referred to
      in the mailing list. This is a very time consuming exercise and will
      deter the majority of application developers. I would therefore like to
      add my vote to the many that have already been cast...please review the
      library documentation. Personally I would like to see some really simple
      examples in the documentation...how to construct, fill, manipulate,
      perform arithmetic on the important classes. Also, how to use the
      array_adaptor class, how to interact with the binding library. Perhaps
      these are already in the Yahoo ublas files section, but unfortunately I
      have not been able to access this as new members are not currently been
      enrolled. If not, I have written a short application that demonstrates
      some of these things that I would be happy to make available as a
      starting point.

      Finally, I would like to thank all those developers who have contributed
      time to developing the ublas and bindings libraries. Both libraries are
      clearly of a particularly high standard.

      Kind regards,

      Russell
    • Michael Stevens
      Hi Russell, ... OK sounds good! ... I think the reason that array_adaptor is not yet a first class citizen is that it is just one of very many possible
      Message 2 of 2 , Dec 2, 2004
        Hi Russell,

        > I have spent a large part of this past week evaluating and experimenting
        > with the ublas and bindings library with a view to employing them in a
        > large coding project in the quasi real-time image processing domain. I
        > have several questions for the ublas development community and would
        > also like to pass on some comments based on my evaluation.
        OK sounds good!

        > 1. What is the status of the array_adaptor class within the ublas library?
        > This class is currently undocumented, however, provides a very important
        > role in providing a method to view data that is not owned by the
        > library. Can developers write applications using this class to access
        > the power of ublas and be confident that it is not suddenly going to
        > disappear in future releases? Is the intention to eventually document
        > the class and make it a first class citizen in the library? In the image
        > processing field the ability to manipulate the image data (which may
        > have been stored by a 3rd party image acquisition library, for example)
        > using ublas is very attractive.

        I think the reason that array_adaptor is not yet a first class citizen is that
        it is just one of very many possible variations. There is such a variety and
        array_adaptor is simply a useful example to build from.
        I think array_adaptor will stay and eventually be documented as a example of a
        storage array. Much more importantly there has been a fair bit of work by
        Toon and me recently on defining the Storage concepts so the interface to
        classes like array_adaptor is clearly defined.

        > 2. Will ublas continue to work with the bindings library (and in
        > particular the ATLAS bindings) in future releases?
        > There has been quite a lot of discussion in the mailing list about
        > protecting access to class members and slimming down the public
        > interface. It appears that as of Boost v1.32 (on MSVC v7.1 platform)
        > this has already started to happen. The ATLAS bindings require access to
        > the ublas::vector.expression() and ublas::matrix.expression() member. In
        > the latest release these functions have been made private resulting in
        > compiler errors. The simplest workaround I have found is to #define
        > BOOST_UBLAS_NESTED_CLASS_DR45 in my application before including the
        > ublas headers as this ensures that the expression() function is public.

        The future of uBLAS and Bindings are closely linked. I hope we can get some
        regression tests into uBLAS so stupid mistakes like the .expression problem
        don't arise in the future.
        Your workaround sounds fine. Hopefully there is a more general fix to the
        bindings that will work with 1.31 and 1.32
        > <begin personal rant>
        > Whilst I am sure that many of the implementors of the ublas library
        > focus on the "theoretical correctness" of the library and its
        > interfaces, much of the power of the library stems from the fact that it
        > can be used to manipulate numerical vectors and matrices efficiently. In
        > this case, efficiently relates not just to the the time taken to develop
        > readable and correct applications, but also to the runtime. In the
        > latter case, the ability to access the optimised linear algebra provided
        > by ATLAS, CBLAS, CLAPACK, etc, and do so through a simple and clean
        > interface, significantly adds to the value of the ublas library. I am
        > therefore a concerned that the push to slim the public interface to the
        > library in future releases may prevent application developers from
        > accessing its real benefits, as demonstrated by the bindings library.
        > Those people driving the design and implementation of the ublas library
        > have unquestionably put an awful lot of effort into the development of
        > this library (and should be very proud of the result) and I feel that it
        > would be a terrible shame to introduce barriers to its adoption by
        > application developers. In many ways, it seems that the forces
        > associated with formal generic programming and the forces associated
        > with practical application development often pull in opposite directions
        > when looking at the fine detail.
        > <end personal rant>
        I think the aim of the current development is to make these interface well
        defined so all this is much less error prone. I think most of the serious
        uBLAS users have the same requirements as you.

        > 3. What is the feeling in the community regarding interoperability
        > between ublas::vector, ublas::matrix and boost::multi_array?
        > This is a topic that has been addressed in some posts in the mailing
        > list, both in relation to adaptors and bindings, but I am unclear of the
        > current situation. The main difficulty referred to in the mailing list
        > seems to relate to the fact that although the storage_order could be
        > defined in the constructor, it was not possible to query this property
        > later. It seems, according to the documentation at least, that
        > multi_array now supports querying of the storage order through the
        > storage_order() member. Personally, I seems completely logically to
        > provide "array adaptors" for multi_array objects, but I cannot comment
        > on its feasibility. Following my comments in section 2, it will not
        > surprise you to learn that I also strongly encourage support for
        > multi_array in the bindings library.
        "array adaptors" for multi_array would be great. I think it just need someone
        with a requirement to do this to implement and document it!


        > 4. As a newcomer to the libraries I have to admit that I found it a very
        > steep learning curve as the documentation is definitely NOT end-user
        > orientated, and I often had to search the mailing list to find a more
        > human readable answer to my queries. In many instances I also had to
        > refer to the source code to research undocumented features referred to
        > in the mailing list. This is a very time consuming exercise and will
        > deter the majority of application developers. I would therefore like to
        > add my vote to the many that have already been cast...please review the
        > library documentation. Personally I would like to see some really simple
        > examples in the documentation...how to construct, fill, manipulate,
        > perform arithmetic on the important classes. Also, how to use the
        > array_adaptor class, how to interact with the binding library. Perhaps
        > these are already in the Yahoo ublas files section, but unfortunately I
        > have not been able to access this as new members are not currently been
        > enrolled. If not, I have written a short application that demonstrates
        > some of these things that I would be happy to make available as a
        > starting point.
        That would be good. Think about using the "Effective uBLAS" wiki to either
        place your documentation or links to a web site with them. That way they will
        be available to all and also can be integrated into the official
        documentation.

        > Finally, I would like to thank all those developers who have contributed
        > time to developing the ublas and bindings libraries. Both libraries are
        > clearly of a particularly high standard.
        :-)

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