wait, scratch that idea, that would throw python syntax errors all over the place.
I was too quick on the send button... On Tue, Aug 25, 2009 at 5:49 PM, Chris Colbert<[email protected]> wrote: > with regards to replacing weave, would it be possible to just use a > function decorator? > > i.e something like: > > @cythonize > def trivial_func(int i): > cdef int j > j = i + 1 > return j > > > I particularly like the thought of this over weave so that I don't > have to "switch gears" in brain from reading python to reading C. > > Cheers, > > Chris > > On Tue, Aug 25, 2009 at 5:21 PM, Fernando Perez<[email protected]> wrote: >> Hi folks, >> >> On Tue, Aug 25, 2009 at 12:08 PM, Kurt Smith<[email protected]> wrote: >>> Weave-like support in Cython -- Fernando Perez (not at the BoF) >>> suggested that Cython could assume the same functionality of >>> scipy.weave (see: http://www.scipy.org/Weave), since scipy.weave is >>> poorly documented and could use more maintenance than it is currently >>> getting. I'm personally very interested in this -- it seems that >>> there is much overlap between scipy.weave and the combination of >>> pyximport & the pure-python mode of Cython. It seems that with a bit >>> of work from an interested user and some guidance from yours truly, we >>> could improve pyximport & Cython's pure-python mode to incorporate the >>> good stuff from scipy.weave, but better ;-) I intend to write-up a >>> CEP with my thoughts sometime in the near future. >>> >> >> Kurt, thanks for resurrecting this comment. Indeed, weave is an >> extremely useful piece of functionality but one that has been somewhat >> neglected for years. There's a lot of good in there though, and the >> need for it is significant. It's *really* cool to do things like: >> >> def prod(m, v): >> """Matrix-vector multiply via weave/blitz++""" >> nrows, ncolumns = m.shape >> assert v.ndim==1 and ncolumns==v.shape[0],"Shape mismatch in prod" >> >> res = np.zeros(nrows, float) >> code = r""" >> for (int i=0; i<nrows; i++) >> { >> for (int j=0; j<ncolumns; j++) >> { >> res(i) += m(i,j)*v(j); >> } >> } >> """ >> err = inline(code,['nrows', 'ncolumns', 'res', 'm', 'v'], verbose=2, >> type_converters=converters.blitz) >> return res >> >> This makes interactive experimentation and the writing of >> loop/indexing-intensive code really easy. But by itself, weave is in >> serious danger of bitrot, and right now Cython has the momentum and >> concentrated effort for this problem domain. >> >> Everyone is extremely impressed with the amazing work you've all done, >> and rooting for cython to continue to improve, as you are solving a >> number of key problems to make python a really complete platform for >> scientific computing. It's been lots of fun to see cython steadily >> attack a number of problems that have been a real issue for years. >> >> So if Cython absorbs/extends/integrates/develops/whatever the good >> ideas and code from weave, so that this type of workflow is also >> supported, it would be great. I am really happy to see f2py grow >> into fwrap, and the weave machinery (or at least parts of it) seems >> like a logical addition to the cython-based toolkit. >> >> One particular use case for which weave.inline was invaluable to me in >> the past was the generation of fast looping code for various >> dimensions. I had to write function evaluation codes where the user >> could supply a C expression (as a string, that would #define NDIM to >> indicate the dimensionality of the problem). I could then easily >> generate a few methods for D=1..6 (the range I needed to cover) that >> would do certain key operations very fast. The bulk of the code used >> numpy arrays to be dimension agnostic, but a few methods really needed >> explicit loops and with weave, it was made completely transparent to >> the user, all of it being done at runtime (for us, needing gcc at >> runtime was OK). I mention this to give you some feedback on the use >> cases for weave (there are others), but I hope that in the end, all of >> this class of functionality will be available through a unified entry >> point, and if that's cython, all the better. >> >> Thanks again to the team for your great work! >> >> Cheers, >> >> f >> _______________________________________________ >> Cython-dev mailing list >> [email protected] >> http://codespeak.net/mailman/listinfo/cython-dev >> > _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
