Robert Bradshaw wrote: > On Sep 30, 2009, at 5:07 PM, Christopher Barker wrote: > > >> Dag Sverre Seljebotn wrote: >> >>> Christopher Barker wrote: >>> Yes, but the existing intro on numpy+cython: >>> a) Lacks quite a bit in several areas >>> b) Is outdated >>> >>> While the tutorial + paper is already written now. >>> >> right -- my pint was that we really should have only one -- if the >> tutorial+paper is the better/more up-to-date one, then by all means >> let's make that the one people find. >> >> >> >>>> However, maybe it's my personal use-case bias, but I think that >>>> numpy is >>>> almost a standard part of Cython use -- I can't think of what I'd >>>> like >>>> to optimize that I wouldn't want to use numpy for! And numpy is >>>> why I >>>> skipped past pyrex and straight to Cython. >>>> >>> Well, take Stefan Behnel, who doesn't use NumPy at all, but rather >>> works >>> with XML documents. >>> >>> Even within science, the whole Sage project (a very important Cython >>> user) don't use that much NumPy either, and in particular not the >>> Cython/NumPy features, as they need exact math which isn't covered by >>> NumPy's dtypes >>> >> OK -- lot's of non-numpy use. >> > > Yep. Sage ships SciPy, and we defer lots of the numerical stuff to > that. We could probably use NumPy more than we do, but for most stuff > fixed-size fixed-precision arrays SIMD operations just doesn't > describe what we do. > > >>> Then you have any kind of wrappers around native libraries. >>> >> yes, but if those native libraries are working with arrays of data, >> numpy may well be a good idea there, too. >> > > I would say that most (non-scientific) libraries don't work with > arrays of data. > > >>> There's enough usecases for Cython without NumPy to make our primary >>> Cython tutorial generic and not targeted for numerical users IMO. >>> >> agreed, though I may never use the stuff used to process XML docs, but >> it gets first class treatment... >> > > I think the main point here is string processing, which is much more > broadly applicable than parsing XML. > > >>> And then you have the question of whether one should have *two* >>> tutorials. Perhaps a very small intro document for numerical users >>> which >>> links heavily into the other documents... >>> >> Sure -- in fact, it often makes lots of sense for there to be >> different >> tutorial focused on different user groups -- either because they have >> different use-cases, or because they have different backgrounds. >> >> I can tell you that I went straight to the numpy+Cython tutorial, >> because I knew I'd want to work primarily with numpy arrays. >> >> We may some day want tutorials for: >> - how to use Cython to wrap C libs >> - how to use Cython to wrap C++ libs >> (maybe targeted for folks that are used to using SWIG, ctypes, >> etc.) >> > > Maybe something like > > Intro > - Brief overview of what Cython is (and is not) > - Building (very simple example, setup.py) -- note that this can be > skipped if using the sage notebook. (Eventually it might be good to > have a link right to the sage notebook for people to try all the > examples out--the setup can be a hurdle, and this gives people a > chance to see how easy and powerful it is to have motivation to > actually set it up on their machines). > - Basics cdef variables, methods(?), and types. cython -a > > All of the above is essential to any use of Cython. We could then > dive into topic-specific tutorials, specifically: > > - NumPy -- this would be the SciPy paper, minus intro stuff > - Calling and wrapping external libraries > - Creating extension classes > - String processing > - Advanced topics (for...from, include, .pxd files) > - Common pitfalls > - Pure mode > - ??? > That's a great idea. Basically just putting the last half of our SciPy tutorial into seperate chapters and link to them (so that they don't have to be read in a particular order) gets us very far. I was thinking about this when writing the tutorial -- which section to put first of:
a) NumPy b) string processing c) wrapping external lib? As they don't build on one another. Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
