Re: [Numpy-discussion] Accessing LAPACK and BLAS from the numpy C API
On Tue, Nov 10, 2009 at 02:43, Fernando Perez wrote: > On Sun, Nov 8, 2009 at 11:43 PM, David Cournapeau > wrote: >> Fernando Perez wrote: >>> On Sat, Nov 7, 2009 at 12:41 PM, Sturla Molden wrote: >>> You find a C function pointer wrapped in a CObject in the ._cpointer attribute. >>> >>> Sorry, in the ._cpointer attribute of what precisely? >> >> If Sturla refers to CObject as defined in the python C API, then the >> underlying lapack functions are not wrapped into a C object (this is not >> done automatically). The lapack_lite functions such as dgeev and co are >> standard python function (with *self and *args args, i.e. wrappers >> around the underlying 'true' lapack function). > > Thanks, David. My question was because Sturla's language seemed to > suggest (at least it did to me) that there was some python object foo > where foo._cpointer would be a poniter to the raw C function one could > then manipulate with ctypes. Perhaps I just misunderstood, but thanks > for clarifying that at least this isn't possible today from pure > python. Only f2py functions have the ._cpointer attribute. In [3]: from scipy import linalg In [4]: linalg.flapack.dgeev._cpointer Out[4]: -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Accessing LAPACK and BLAS from the numpy C API
On Sun, Nov 8, 2009 at 11:43 PM, David Cournapeau wrote: > Fernando Perez wrote: >> On Sat, Nov 7, 2009 at 12:41 PM, Sturla Molden wrote: >> >>> You find a C function pointer wrapped in a CObject in the ._cpointer >>> attribute. >>> >> >> Sorry, in the ._cpointer attribute of what precisely? > > If Sturla refers to CObject as defined in the python C API, then the > underlying lapack functions are not wrapped into a C object (this is not > done automatically). The lapack_lite functions such as dgeev and co are > standard python function (with *self and *args args, i.e. wrappers > around the underlying 'true' lapack function). Thanks, David. My question was because Sturla's language seemed to suggest (at least it did to me) that there was some python object foo where foo._cpointer would be a poniter to the raw C function one could then manipulate with ctypes. Perhaps I just misunderstood, but thanks for clarifying that at least this isn't possible today from pure python. Cheers, f ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Accessing LAPACK and BLAS from the numpy C API
On Tue, Nov 10, 2009 at 4:08 AM, Jake VanderPlas wrote: >>The safe way to access them, since they are not exposed, is to call the >>function at the python level in your C code, but I don't think that's >>what you want, > > I want to avoid calling functions at the python level, because of the > overhead for multiple calls within nested loops. Yes, there is no question this would be useful, but we don't have the mechanism (yet) to make that possible. We have added some infrastructure at the build level to make C libraries available to 3rd parties, but more is needed for blas/lapack. > ...and directly call the BLAS fortran library. This pattern works on > my system (linux, using the system BLAS/LAPACK libraries). Is this a > form that will work across different OSs and different installs? Not at all. What you have done here is simply link against whatever blas/lapack is found on your system. It will not work on platforms without development package of blas/lapack, with different fortran name mangling, etc... That's certainly a valid option until we support this better in numpy/scipy, though. David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Accessing LAPACK and BLAS from the numpy C API
>The safe way to access them, since they are not exposed, is to call the >function at the python level in your C code, but I don't think that's >what you want, I want to avoid calling functions at the python level, because of the overhead for multiple calls within nested loops. I may have a solution: I've managed to get access to the BLAS fortran library by using in the setup.py file: from distutils.core import Extension from numpy.distutils import system_info myextension = Extension(<...> library_dirs = system_info.blas_opt_info().get_lib_dirs(), <...>) Then in my C++ code I can declare, e.g. extern "C" double ddot_(const int *N, const double *DX, const int *INCX, const double *DY, const int *INCY); ...and directly call the BLAS fortran library. This pattern works on my system (linux, using the system BLAS/LAPACK libraries). Is this a form that will work across different OSs and different installs? -Jake ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Accessing LAPACK and BLAS from the numpy C API
Fernando Perez wrote: > On Sat, Nov 7, 2009 at 12:41 PM, Sturla Molden wrote: > >> You find a C function pointer wrapped in a CObject in the ._cpointer >> attribute. >> > > Sorry, in the ._cpointer attribute of what precisely? If Sturla refers to CObject as defined in the python C API, then the underlying lapack functions are not wrapped into a C object (this is not done automatically). The lapack_lite functions such as dgeev and co are standard python function (with *self and *args args, i.e. wrappers around the underlying 'true' lapack function). The safe way to access them, since they are not exposed, is to call the function at the python level in your C code, but I don't think that's what you want, cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Accessing LAPACK and BLAS from the numpy C API
On Sat, Nov 7, 2009 at 12:41 PM, Sturla Molden wrote: > You find a C function pointer wrapped in a CObject in the ._cpointer > attribute. Sorry, in the ._cpointer attribute of what precisely? I tried introspecting in various parts of np.linalg (down to the 'bare' lapack_lite functions) and couldn't find anything with a _cpointer attribute. Thanks, f ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Accessing LAPACK and BLAS from the numpy C API
Jake VanderPlas wrote: > Does anybody know a > way to directly access the numpy.linalg routines from a C extension, > without the overhead of a python callback? Thanks for the help. > You find a C function pointer wrapped in a CObject in the ._cpointer attribute. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Accessing LAPACK and BLAS from the numpy C API
Hello, I'm working on wrapping a set of C++ routines for manifold learning (LLE, Isomap, LTSA, etc) in python. In the LLE routine, it is necessary to loop through the input points and perform an svd of each local covariance matrix. Presently I have my own C-LAPACK wrapper that I call within a C loop, but this seems non-ideal because numpy already wraps LAPACK/ATLAS for linear algebra. Does anybody know a way to directly access the numpy.linalg routines from a C extension, without the overhead of a python callback? Thanks for the help. -Jake ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
