On 19 September 2012 00:15, Robert Bradshaw <rober...@gmail.com> wrote: > On Tue, Sep 18, 2012 at 3:42 PM, mark florisson > <markflorisso...@gmail.com> wrote: >> On 18 September 2012 20:55, Christoph Groth <c...@falma.de> wrote: >>> Hello, >>> >>> I have written a python extension module, tinyarray, (to be made public >>> soon) which implements an important subset of numpy optimized for >>> _small_ arrays. Tinyarrays are immutable, which makes them usable as >>> dictionary keys. >>> >>> Some important operations, i.e. creation of a small array from a tuple >>> or the scalar product of two small arrays are 10 to 45 times faster than >>> with numpy. This can really boost the performance of programs which use >>> small numpy arrays. (I know that numpy is meant to be used for large >>> arrays, but there are legitimate uses of small arrays as well.) >>> >>> It would be great if Cython could support tinyarrays. Right now, it >>> doesn't. See >>> http://article.gmane.org/gmane.comp.python.cython.user/7329 >>> >>> (As a temporary workaround, I have to made the buffers writable. But >>> this breaks strict immutability.) >>> >>> Would fixing this be a lot of work? >> >> That depends on how we implement it. A 'const' keyword has been >> discussed in general. This would be a little more work, since it needs >> grammar modifications. Also, there would be a difference between >> declaring the data and the variable const, i.e. 'const double[:]' vs >> 'double[:] const', which I personally find bothersome. >> >> Using flags are obvious, like the ones in cython.view, i.e. >> double[:view.readonly], but the problem with that is which axis to >> choose (or any axis?), and we don't have a way of combining flags. So >> we would not only need view.contiguous, but also >> view.contiguous_readonly etc. > > I'd much rather be able to write view.readonly & view.contiguous than > come up with flags specifying the various permutations.
Dag and I discussed it last year and decided to go for the combinations, e.g. indirect_contiguous instead of indirect & contiguous. It looks a lot like flags, so perhaps it should use |. Either way I'm not too fond of the flags. >> Without a greater plan for 'const' I think it might be awkward to use >> for this purpose. I think the flags are apt, and should be used in the >> first dimension. If we wait for other people to comment we could give >> you pointers if you want to give implementing it a swing, it wouldn't >> be too hard. > > Coincidentally, I actually implemented rudimentary const support a > couple of days ago. It's not perfect, but at least it allows you to > provide the correct declarations to deal with const polluted^H^H^H^H > correct code (including const c++ class methods, for which there was > simply no workaround). I just need to write some tests before I feel > comfortable pushing it. > > That said, I think a flag is a good fit here, though const could work as well. Oh that's great, either would be good, but if we have const then using that for memoryviews would be more consistent. Does this distinguish between const * and * const? > - Robert > _______________________________________________ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
