On Jun 15, 2009, at 9:12 AM, Dag Sverre Seljebotn wrote: > Thanks to everybody who contributed to the discussion on a Cython > array > type last week! Here's a summary to attempt focusing the discussion. > > There are now two CEPs: > - CEP 517, array type: http://wiki.cython.org/enhancements/array > - CEP 518, SIMD operations: http://wiki.cython.org/enhancements/simd > > I mostly just added a "what does this facilitate"-section is added > near > the beginning of each, and the multidimensional aspect of the > arrays has > been emphasised. No need to reread it.
Looks good. I assume this supersedes http://wiki.cython.org/ enhancements/buffersyntax ; are there any other wiki pages that are made obsolete by these proposals? > The story is this: > > a) I can only commit to implementing CEP 517 this time around > > b) The arrays themselves/CEP 517 can without loosing *too* much be > done as a library (though I would prefer them as builtins myself). > However SIMD/CEP 518 depends on building the arrays into the language, > and switching approaches later would mean redoing some stuff. > Therefore > SIMD (and the numerical roadmap in general) keeps popping into the > discussion. > > c) It would be nice to finally settle a roadmap for numerics in > Cython > (how far will the language be bent for the benefit of numerics), for > instance to economize on discussions when questions pop up on the > mailing list (and make plans). These two CEPs would create one such > roadmap. > > d) CEP 518 isn't a lot of work (totally doable in a GSoC next > year...though of course not at the expense of e.g. a full Python > compatability GSoC or similar). > > Key impressions from last week: > > a) Numerical users seem positive about all of this. > b) Robert Bradshaw said: > > I am not opposed to this feature, despite it being off the path of > being a good, optimizing Python compiler with easy glue to external > code, as long as it doesn't intrude on the language too much. Mostly, > this is because there is so much interest in using Cython in a > numerical processing context. I do, however, have some reservations. > > [I believe the reservations were all taken care of.] I still have some questions, but I am certainly in favor of something like this happening. One thing that isn't quite clear is how exactly the reference counting/memory allocation is going to work. You give an example of explicitly creating an int[:,:] via int[:100,:100](). Would some kind of memoryview be created in the background? A string to hold the data? (This doesn't have to be decided now, just curious.) This is also needed for the copy "method," or any implicit copying that happens. On a related note, it's still a bit unclear how these things can be passed around and stored. Are they just a Py_buffer + PyObject*? (I'm hoping you're thinking they can be passed around and stored with ease, with allocation either take care of by the corresponding object (which will clean up the memory when it gets collected) or if there is no object attached, the user needs to treat it as they would a raw pointer). Until CEP 518, how would arithmetic happen? (Assuming I'm to lazy to write the loops myself) would I create two numpy objects to wrap them, add those objects, and then "unpack" the result. For large enough datasets, that's not too much overhead. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
