On Tue, Sep 18, 2012 at 3:42 PM, mark florisson <markflorisson88@gmail.com> wrote:
On 18 September 2012 20:55, Christoph Groth <cwg@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.
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. - Robert