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
- ???

All of the above would assume only the background of the (shortish)  
intro chapter(s), and be relatively self-contained.

There should also be a reference. This would contain things like  
specific optimizations, directives, language details, and would be  
heavily linked to from the above.

- Robert

_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to