[SciPy-User] RZ Factorization

Del Citto Francesco francesco.delcitto at sauber-motorsport.com
Thu Sep 4 10:22:53 EDT 2014


Wow, precious hints, thanks a lot!

> -----Original Message-----
> From: scipy-user-bounces at scipy.org [mailto:scipy-user-bounces at scipy.org] On Behalf Of Sturla Molden
> Sent: Thursday, September 04, 2014 4:19 PM
> To: scipy-user at scipy.org
> Subject: Re: [SciPy-User] RZ Factorization
> 
> Del Citto Francesco <francesco.delcitto at sauber-motorsport.com> wrote:
> 
> > How do you create an extension module for this task? Could you give me some hint?
> 
> To use f2py, just do it the same way as SciPy. Create a .pyf with the LAPACK prototypes you need and a
> setup.py file, compile and link with LAPACK. Be aware that there can be an ABI problem if you use
> Apple Accelerate framework, which is why SciPy has special wrappers for Accelerate.
> 
> Personally I prefer to write a C function that uses the NumPy C API, then I call this C function from
> Cython. I do not use typed memoryviews in Cython as the buffer acquisition incurs a lot of overhead. I
> try to keep my Cython files clean of any numerical stuff. They are just plain wrappers to avoid the
> boiler-plate Python C API coding (and refcounting, if possible).
> 
> If you want to call Fortran from Python in a portable way, you should use the Fortran 2003 ISO C
> bindings, and then call this fortran wrapper from Cython. There is a program called "fwrap" which will
> autogenerate these Fortran wrappers. This way of wrapping Fortran whould generally avoid any ABI
> problems. I have not used fwrap, but I always use Fortran 2003.
> 
> Then I typically end up with a calling cascade like this:
> 
> 
> Python code
>        |
> Cython wrapper (avoid Python C API)
>        |
> C function using NumPy C API
>        |
> Fortran 2003 wrapper (ISO C binding)
>        |
> Fortran 95 modules (my own numerical code)
>        |
> Fortran 77 LAPACK subroutine
> 
> 
> My actual numerical code would be in the Python and Fortran 95 layers.
> 
> Also note that there is no f2py layer in this calling cascade. This gives me full control over what
> happens at each step, including memory use, but incurs more boiler-plate coding for me.
> 
> 
> Using f2py simplifies the cascade:
> 
> Python code
>        |
> f2py wrapper
> (little control over the overhead here)
>        |
> Fortran 95 modules
>        |
> Fortran 77 LAPACK subroutine
> 
> I used to do this before. It works ok if f2py overhead is acceptable.
> 
> 
> SciPy is even more puristic and usually does this:
> 
> Python code
> (all numerics except LAPACK)
>        |
> f2py wrapper
> (don't care what happens here)
>        |
> Fortran 77 LAPACK subroutine
> 
> 
> 
> Do whatever you prefer and fits you best :)
> 
> 
> Sturla
> 
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user



More information about the SciPy-User mailing list