Re: [Numpy-discussion] f2py - a recap
Hi, Few months ago I joined a group of system biologist and I have been busy with new projects (mostly C++ based). So I haven't had a chance to work on f2py. However, I am still around to fix f2py bugs and maintain/support numpy.f2py (as long as current numpy maintainers allow it..) -- as a rule these tasks do not take much of my time. I have also rewritten f2py users guide for numpy.f2py and submitted a paper on f2py. I'll make them available when I get some more time.. Regards, still-kicking-yoursly, Pearu On Thu, July 24, 2008 1:46 am, Fernando Perez wrote: > Howdy, > > On Wed, Jul 23, 2008 at 3:18 PM, Stéfan van der Walt <[EMAIL PROTECTED]> > wrote: >> 2008/7/23 Fernando Perez <[EMAIL PROTECTED]>: > >> I agree (with your previous e-mail) that it would be good to have some >> documentation, so if you could give me some pointers on *what* to >> document (I haven't used f2py much), then I'll try my best to get >> around to it. > > Well, I think my 'recap' message earlier in this thread points to a > few issues that can probably be addressed quickly (the 'instead' error > in the help, the doc/docs dichotomy needs to be cleaned up so a single > documentation directory exists, etc). I'm also attaching a set of > very old notes I wrote years ago on f2py that you are free to use in > any way you see fit. I gave them a 2-minute rst treatment but didn't > edit them at all, so they may be somewhat outdated (I originally wrote > them in 2002 I think). > > If Pearu has moved to greener pastures, f2py could certainly use an > adoptive parent. It happens to be a really important piece of > infrastructure and for the most part it works fairly well. I think > a litlte bit of cleanup/doc integration with the rest of numpy is > probably all that's needed, so it could be a good project for someone > to adopt that would potentially be low-demand yet quite useful. > > Cheers, > > f > ___ > Numpy-discussion mailing list > Numpy-discussion@scipy.org > http://projects.scipy.org/mailman/listinfo/numpy-discussion > ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] f2py - a recap
Howdy, On Wed, Jul 23, 2008 at 3:18 PM, Stéfan van der Walt <[EMAIL PROTECTED]> wrote: > 2008/7/23 Fernando Perez <[EMAIL PROTECTED]>: > I agree (with your previous e-mail) that it would be good to have some > documentation, so if you could give me some pointers on *what* to > document (I haven't used f2py much), then I'll try my best to get > around to it. Well, I think my 'recap' message earlier in this thread points to a few issues that can probably be addressed quickly (the 'instead' error in the help, the doc/docs dichotomy needs to be cleaned up so a single documentation directory exists, etc). I'm also attaching a set of very old notes I wrote years ago on f2py that you are free to use in any way you see fit. I gave them a 2-minute rst treatment but didn't edit them at all, so they may be somewhat outdated (I originally wrote them in 2002 I think). If Pearu has moved to greener pastures, f2py could certainly use an adoptive parent. It happens to be a really important piece of infrastructure and for the most part it works fairly well. I think a litlte bit of cleanup/doc integration with the rest of numpy is probably all that's needed, so it could be a good project for someone to adopt that would potentially be low-demand yet quite useful. Cheers, f F2PY Author: Fernando Perez <[EMAIL PROTECTED]>. Please send all comments/corrections to this address. This is a rough set of notes on how to use f2py. It does NOT substitute the official manual, but is rather meant to be used alongside with it. For any non-trivial poject involving f2py, one should also keep at hand Pierre Schnizer's excellent 'A short introduction to F2PY', available from http://fubphpc.tu-graz.ac.at/~pierre/f2py_tutorial.tar.gz Usage for the impatient --- Start by building a scratch signature file automatically from your Fortran sources (in this case all, you can choose only those .f files you need):: f2py -m MODULENAME -h MODULENAME.pyf *.f This writes the file MODULENAME.pyf, making the best guesses it can from the Fortran sources. It builds an interface for the module to be accessed as 'import adap1d' from python. You will then edit the .pyf file to fine-tune the python interface exhibited by the resulting extension. This means for example making unnecessary scratch areas or array dimensions hidden, or making certain parameters be optional and take a default value. Then, write your setup.py file using distutils, and list the .pyf file along with the Fortran sources it is meant to wrap. f2py will build the module for you automatically, respecting all the interface specifications you made in the .pyf file. This approach is ultimately far easier than trying to get all the declarations (especially dependencies) right through Cf2py directives in the Fortran sources. While that may seem appealing at first, experience seems to show that it's ultimately far more time-consuming and prone to subtle errors. Using this approach, the first f2py pass can do the bulk of the interface writing and only fine-tuning needs to be done manually. I would only recommend embedded Cf2py directives for very simple problems (where it works very well). The only drawback of this approach is that the interface and the original Fortran source lie in different files, which need to be kept in sync. This increases a bit the chances of forgetting to update the .pyf file if the Fortran interface changes (adding a parameter, for example). However, the benefit of having explicit, clear control over f2py's behavior far outweighs this concern. Choosing a default compiler --- Set the FC_VENDOR environment variable. This will then prevent f2py from testing all the compilers it knows about. Using Cf2py directives -- For simpler cases you may choose to go the route of Cf2py directives. Below are some tips and examples for this approach. Here's the signature of a simple Fortran routine:: subroutine phipol(j,mm,nodes,wei,nn,x,phi,wrk) implicit real *8 (a-h, o-z) real *8 nodes(*),wei(*),x(*),wrk(*),phi(*) real *8 sum, one, two, half The above is correctly handled by f2py, but it can't know what is meant to be input/output and what the relations between the various variables are (such as integers which are array dimensions). If we add the following f2py directives, the generated python interface is a lot nicer:: c subroutine phipol(j,mm,nodes,wei,nn,x,phi,wrk) c c Lines with Cf2py in them are directives for f2py to generate a better c python interface. These must come _before_ the Fortran variable c declarations so we can control the dimension of the arrays in Python. c c Inputs: Cf2py integer check(0<=j && j>> import bar >>> bar.foo([1,2,3]) 6.0 The f2py mailing list archives contain more examples about wrapping C functions with f2py. Passing offset arr
Re: [Numpy-discussion] f2py - a recap
On Wed, Jul 23, 2008 at 17:18, Stéfan van der Walt <[EMAIL PROTECTED]> wrote: > 2008/7/23 Fernando Perez <[EMAIL PROTECTED]>: >> I'm just reposting here to see if anyone with a stake in f2py has an >> opinion/advice on the points below. F2py feels very much in >> autopilot/drifting into the icebergs mode right now. Is that correct >> assessment? >> >> If there's any guidance on where to go, I can at least file tickets on >> these points, but I don't want to create unnecessary tickets on trac >> if others feel the current situation is satisfactory and it's just me >> who is confused. > > As far as I understand, Pearu is busy developing g3 of f2py. I think he's been busy doing other things for the past few months, at least. > Does > that mean that f2py in NumPy is effectively unmaintained? I hope not. We'll try to fix bugs as they come up, but this is, as always, subject to the vagaries of free time. It is very unlikely to grow new features. -- 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://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] f2py - a recap
2008/7/23 Fernando Perez <[EMAIL PROTECTED]>: > I'm just reposting here to see if anyone with a stake in f2py has an > opinion/advice on the points below. F2py feels very much in > autopilot/drifting into the icebergs mode right now. Is that correct > assessment? > > If there's any guidance on where to go, I can at least file tickets on > these points, but I don't want to create unnecessary tickets on trac > if others feel the current situation is satisfactory and it's just me > who is confused. As far as I understand, Pearu is busy developing g3 of f2py. Does that mean that f2py in NumPy is effectively unmaintained? I hope not. I agree (with your previous e-mail) that it would be good to have some documentation, so if you could give me some pointers on *what* to document (I haven't used f2py much), then I'll try my best to get around to it. Cheers Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] f2py - a recap
Hi all, I'm just reposting here to see if anyone with a stake in f2py has an opinion/advice on the points below. F2py feels very much in autopilot/drifting into the icebergs mode right now. Is that correct assessment? If there's any guidance on where to go, I can at least file tickets on these points, but I don't want to create unnecessary tickets on trac if others feel the current situation is satisfactory and it's just me who is confused. Cheers, f On Fri, Jul 18, 2008 at 9:00 PM, Fernando Perez <[EMAIL PROTECTED]> wrote: > Howdy, > > today's exercise with f2py left some lessons learned, mostly thanks to > Robert's excellent help, for which I'm grateful. > > I'd like to recap here what we have, mostly to decide what changes (if > any) should go into numpy to make the experience less "interesting" > for future users: > > - Remove the f2py_options flag from > numpy.distutils.extension.Extension? If so, do options like > '--debug_capi' get correctly passed via setup.cfg? > > This flag is potentially very confusing, because only *some* f2py > options get actually set this way, while others need to be set in > calls to config_fc. > > - How to properly set the compiler options in a setup.py file? Robert > suggested the setup.cfg file, but this doesn't get picked up unless > config_fc is explicitly called by the user: > > ./setup.py config_fc etc... > > This is perhaps a distutils problem, but I don't know if we can > solve it more cleanly. It seems to me that it should be possible to > provide a setup.py file that can be used simply as > > ./setup.py install > > (with the necessary setup.cfg file sitting next to it). I'm thinking > here of what we need to do when showing how 'easy' these tools are > for scientists migrating from matlab, for example. Obscure, special > purpose incantations tend to tarnish our message of ease :) > > - Should the 'instead' word be removed from the f2py docs regarding > the use of .pyf sources? It appears to be a mistake, which threw at > least me for a loop for a while. > > - Why does f2py in the source tree have *both* a doc/ and a docs/ > directory? It's really confusing to see this. > > f2py happens to be a very important tool, not just because scipy > couldn't build without it, but also to position python as a credible > integration language for scientific work. So I hope we can make using > it as easy and robust as is technically feasible. > > Cheers, > > f > ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] f2py - a recap
Howdy, today's exercise with f2py left some lessons learned, mostly thanks to Robert's excellent help, for which I'm grateful. I'd like to recap here what we have, mostly to decide what changes (if any) should go into numpy to make the experience less "interesting" for future users: - Remove the f2py_options flag from numpy.distutils.extension.Extension? If so, do options like '--debug_capi' get correctly passed via setup.cfg? This flag is potentially very confusing, because only *some* f2py options get actually set this way, while others need to be set in calls to config_fc. - How to properly set the compiler options in a setup.py file? Robert suggested the setup.cfg file, but this doesn't get picked up unless config_fc is explicitly called by the user: ./setup.py config_fc etc... This is perhaps a distutils problem, but I don't know if we can solve it more cleanly. It seems to me that it should be possible to provide a setup.py file that can be used simply as ./setup.py install (with the necessary setup.cfg file sitting next to it). I'm thinking here of what we need to do when showing how 'easy' these tools are for scientists migrating from matlab, for example. Obscure, special purpose incantations tend to tarnish our message of ease :) - Should the 'instead' word be removed from the f2py docs regarding the use of .pyf sources? It appears to be a mistake, which threw at least me for a loop for a while. - Why does f2py in the source tree have *both* a doc/ and a docs/ directory? It's really confusing to see this. f2py happens to be a very important tool, not just because scipy couldn't build without it, but also to position python as a credible integration language for scientific work. So I hope we can make using it as easy and robust as is technically feasible. Cheers, f ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
