[SciPy-dev] Extensions linking to libraries used by numpy/scipy
robert.kern at gmail.com
Tue Mar 7 00:16:17 CST 2006
Tom Loredo wrote:
> Robert, thanks for the interesting suggestions!
> Robert Kern wrote:
>>Also, I remember asking Pearu to expose the raw function pointer in the fortran
>>object wrapper. The idea was to be able to allow f2py callback functions to be
>>f2py'ed subroutines themselves, and have everything go really, really fast.
>>In : linalg.flapack.dgetrf._cpointer
>>Out: <PyCObject object at 0xd650>
>>I believe this actually gives you the function pointer to DGETRF_.
> Alas, this is what I see on OS X (10.3.9):
> In : from scipy import linalg
> In : linalg.flapack.dgetrf._cpointer
> AttributeError: 'module' object has no attribute 'flapack'
> In : linalg.lapack.dgetrf._cpointer
> AttributeError: 'module' object has no attribute 'lapack'
> In : linalg.clapack.dgetrf._cpointer
> AttributeError: 'module' object has no attribute 'clapack'
> This is presumably related to whatever is behind the scipy.test()
> warnings about missing blas/lapack on OS X that I and others have reported
> here, presumably reflecting the use of Apple veclib stuff. Any
> ideas on a portable way to try this?
I dunno. I'm using OS X 10.4, although I think I build with ATLAS. I think you
should at least have flapack. Can you successfully call any of the functions
from scipy.linalg? What versions of numpy/scipy are you using? Can you try "from
scipy.linalg import flapack"? What does
In : from numpy import linalg as n_linalg
In : from scipy import linalg as s_linalg
In : n_linalg is s_linalg
>>Or you could
>>just accept the fortran object itself, and access the function pointer from the
>>PyFortranObject structure itself.
>>Ah, now I've rambled myself to the right answer. Don't pay attention to anything
>>but the last sentence of the previous paragraph. AFAICT, this is a new approach,
>>so you can be our guinea pig.
> I don't know how to pursue this. I'll have to dig more into
> the f2py docs to understand it.
Probably the most straightforward way is to use the ._cpointer, actually. You
can read about the PyCObject structure in the Python documentation, I believe.
My final suggestion probably requires #includeing the fortranobject.h header
from f2py, which makes things a bit more complicated.
> And since I have the attention of the person behind random/mtrand 8-),
> I am also wrapping some RNGs in Fortran (e.g., multivariate t), and
> wondering if there is a way to have them call Numpy's "rand" (or
> standard_normal, etc.). I thought perhaps I could try your trick, but:
> In : random.rand
> Out: <built-in method rand of mtrand.RandomState object at 0x3e110>
> In : random.rand._cpointer
> AttributeError: 'builtin_function_or_method' object has no attribute '_cpointer'
> I presume this is because mtrand is not built with f2py.
Indeed it is not. The module itself is written using Pyrex, and I don't think
there is any reasonable hope of getting Pyrex to do a similar trick. One of
these weekends, I am going to rewrite it in pure C and expose an API with a
similar mechanism as numpy's. I think the extension has stabilized enough that
the benefits of keeping it in Pyrex don't outweigh the usefulness of a C API.
Well, maybe that's not quite true. Let me think about it. If anyone wants to
make a stab at this, let me know. I have a few crazy ideas floating in my head now.
robert.kern at gmail.com
"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
More information about the Scipy-dev