On Oct 1, 2009, at 9:22 AM, Christopher Barker wrote: > Robert Bradshaw wrote: >>>> 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. > > It might be interesting to do a survey, but I can, off the top of my > head, think of a couple broad categories that I've worked with: > - text-oriented : not numpy > - image processing: numpy could/should play a role here > - scientific/numerical: duh! > - GUI: numpy could/should play a role here, too. mainly for > graphics, > etc. > - GIS: numpy does/could/should play a role here, too. > > As an example, if pyOpenGL didn't work with numpy arrays, it would be > crippled -- or it would have to provide its own data types for > storing/manipulating big blocks of data. > > Any C library is going to work with one or both of two things: text > and > numbers -- what fraction of libs only work with text?
Just for fun I did a quick survey of the libraries we access from Cython in Sage (which is probably not typical, but at least is a large set I can say something about): - Neither string processing nor obvious application of NumPy arrays: cliquer, cvxopt, ecl (soon?), ecm, elliptic_curves, flint, gaplib (soon?), givaro, gmp/mpir, iml, lcalc, fplll, libgcrypt, linbox, m4ri, mpfi, mpfr, ntl, palp, pari, polybori, polytopes, pynac (ginac), quaddouble, qs, ratpoints, singular, symmetrica, sympow, zn_poly. - Could potentially use NumPy arrays: ghmm, gd, gsl, lapak. - Non-trivial string processing: Nothing we wrap with Cython (that I know of off the top of my head). Of course there's stdlib, stdio, math, etc. as well. Often we wrap things as (semi-)opaque objects, call methods on them, etc. That being said, I think the scientific/numerical audience is (currently at least) one of the largest audiences for Cython, and it's important to cater to them. > Of course, what I'm really doing here is advocating for an nd-array in > the standard lib... Yeah. The buffer interface is a nice step in that direction though. >> 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). > > Sage is wonderful, but I'd not like to see it get too tied into > Cython... Well, at least we don't call it SageX anymore ;). I'm thinking more of a "try it now" kind of link. - Robert > _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
