Hi, I am new to the matrix functionality of ublas and would like to ask a couple of questions. What I want to do is use the matrix data structures from ublas, together with a vendor supplied lapack (mkl). The issue is that , lapack acts on raw pointers to the matrix data, which, most of the time, it assumes to be contiguous – or some striding info is requested. Here are the questions: a) it is not clear to me that the storage is guaranteed to be contiguous. What would be the appropriate storage class to use? I would prefer that this is not stl-vector-based choice, since this is no longer guaranteed (to my knowledge) to possess this property. b) is there a way to wrap the data structure into a reference counted pointer? There would be a few benefits to this, as using the same matrix from different threads. Also, obviously, sharing the same data from many matrices, views to matrices etc. Also, very importantly to me, I would like to have the ability to “create” a matrix form an existing raw pointer, by “dressing” it into a ref-counted one, therefore separating the data ownership from the matrix functionality. Is there an example that does something along these lines? Thank you very much, in advance, for your help, Petros
On 2011-03-29 20:32, petros wrote:
Hi, I am new to the matrix functionality of ublas and would like to ask a couple of questions. What I want to do is use the matrix data structures from ublas, together with a vendor supplied lapack (mkl). The issue is that , lapack acts on raw pointers to the matrix data, which, most of the time, it assumes to be contiguous – or some striding info is requested. Here are the questions: a) it is not clear to me that the storage is guaranteed to be contiguous. What would be the appropriate storage class to use? I would prefer that this is not stl-vector-based choice, since this is no longer guaranteed (to my knowledge) to possess this property. b) is there a way to wrap the data structure into a reference counted pointer? There would be a few benefits to this, as using the same matrix from different threads. Also, obviously, sharing the same data from many matrices, views to matrices etc. Also, very importantly to me, I would like to have the ability to “create” a matrix form an existing raw pointer, by “dressing” it into a ref-counted one, therefore separating the data ownership from the matrix functionality. Is there an example that does something along these lines? Thank you very much, in advance, for your help, Petros
Hello Petros, are you aware of Boost.NumericBindings library, which is under development? It provides modern-C++-glue between numeric algorithms such as those provided by LAPACK, BLAS, and matrix and vector containers such as those provided by uBLAS, eigen, MTL, and more. The library may be found here: http://svn.boost.org/svn/boost/sandbox/numeric_bindings/ Cheers, Rutger
Hi Rutger, This seems like a very thorough effort. However, a bit tangential to my questions, but that is all right. I do have already written, a fair amount of code using uBlas matrices and mkl and would like to clean it up; so I cannot afford to redo everything now. Also, if I may, there are benefits in wrapping the driver functions into classes rather than functions (albeit template), the primary one being wrapping all the necessary workspace related functionality, away from the user and solving the allocation size issues for them( reusability can be served by the persistence of the class members, now, a luxury that was not there in fortran ). Of course, if I had the bindings machinery at the time, things would be much better for the wrapping. Having said all that, I will definitely look more into it when I have more time. Thank you again, Petros -----Original Message----- From: Rutger ter Borg Sent: Tuesday, March 29, 2011 3:53 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Matrix of external data On 2011-03-29 20:32, petros wrote:
Hi, I am new to the matrix functionality of ublas and would like to ask a couple of questions. What I want to do is use the matrix data structures from ublas, together with a vendor supplied lapack (mkl). The issue is that , lapack acts on raw pointers to the matrix data, which, most of the time, it assumes to be contiguous – or some striding info is requested. Here are the questions: a) it is not clear to me that the storage is guaranteed to be contiguous. What would be the appropriate storage class to use? I would prefer that this is not stl-vector-based choice, since this is no longer guaranteed (to my knowledge) to possess this property. b) is there a way to wrap the data structure into a reference counted pointer? There would be a few benefits to this, as using the same matrix from different threads. Also, obviously, sharing the same data from many matrices, views to matrices etc. Also, very importantly to me, I would like to have the ability to “create” a matrix form an existing raw pointer, by “dressing” it into a ref-counted one, therefore separating the data ownership from the matrix functionality. Is there an example that does something along these lines? Thank you very much, in advance, for your help, Petros
Hello Petros, are you aware of Boost.NumericBindings library, which is under development? It provides modern-C++-glue between numeric algorithms such as those provided by LAPACK, BLAS, and matrix and vector containers such as those provided by uBLAS, eigen, MTL, and more. The library may be found here: http://svn.boost.org/svn/boost/sandbox/numeric_bindings/ Cheers, Rutger _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 03/29/2011 10:40 PM, petros wrote:
Hi Rutger, This seems like a very thorough effort. However, a bit tangential to my questions, but that is all right. I do have already written, a fair amount of code using uBlas matrices and mkl and would like to clean it up; so I cannot afford to redo everything now. Also, if I may, there are benefits in wrapping the driver functions into classes rather than functions (albeit template), the primary one being wrapping all the necessary workspace related functionality, away from the user and solving the allocation size issues for them( reusability can be served by the persistence of the class members, now, a luxury that was not there in fortran ). Of course, if I had the bindings machinery at the time, things would be much better for the wrapping. Having said all that, I will definitely look more into it when I have more time. Thank you again, Petros
Hello Petros, the free driver functions are there for convenience. Further down the chain, classes help out with partial specialization, and all workspace allocation (which can be either minimal, optimal, or user-defined). Also noteworthy is that both Fortran-based backends (plain netlib, MKL, etc.) and C-based backends (CBLAS, ATLAS's LAPACK functions) are supported by setting a preprocessor variable only. If you are looking for more detailed answers on your original questions, your best bet might be to write to the ublas mailing list. Cheers, Rutger
Thank you Rutger. I will look into it. Is there any documentation on the software?
Any examples for usage in the end of all?
Best Regards,
Petros
PS: I did try to get to the uBlas mailing list, followed the links and ended up where I started from.
Maybe I did something wrong but retraced the steps and came out at the same point ;-))
---- Rutger ter Borg
On 03/29/2011 10:40 PM, petros wrote:
Hi Rutger, This seems like a very thorough effort. However, a bit tangential to my questions, but that is all right. I do have already written, a fair amount of code using uBlas matrices and mkl and would like to clean it up; so I cannot afford to redo everything now. Also, if I may, there are benefits in wrapping the driver functions into classes rather than functions (albeit template), the primary one being wrapping all the necessary workspace related functionality, away from the user and solving the allocation size issues for them( reusability can be served by the persistence of the class members, now, a luxury that was not there in fortran ). Of course, if I had the bindings machinery at the time, things would be much better for the wrapping. Having said all that, I will definitely look more into it when I have more time. Thank you again, Petros
Hello Petros,
the free driver functions are there for convenience. Further down the chain, classes help out with partial specialization, and all workspace allocation (which can be either minimal, optimal, or user-defined). Also noteworthy is that both Fortran-based backends (plain netlib, MKL, etc.) and C-based backends (CBLAS, ATLAS's LAPACK functions) are supported by setting a preprocessor variable only.
If you are looking for more detailed answers on your original questions, your best bet might be to write to the ublas mailing list.
Cheers,
Rutger
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 03/30/2011 05:44 PM, pmamales@nyc.rr.com wrote:
Thank you Rutger. I will look into it. Is there any documentation on the software? Any examples for usage in the end of all? Best Regards, Petros PS: I did try to get to the uBlas mailing list, followed the links and ended up where I started from. Maybe I did something wrong but retraced the steps and came out at the same point ;-))
For references to the (albeit incomplete) documentation, please see the NumericBindings entry at https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction for some example code, you could inspect the test cases (in the libs subdir). HtH, Cheers, Rutger
participants (3)
-
petros -
pmamales＠nyc.rr.com
-
Rutger ter Borg