Caveat: I no nothing about fused types in Cython. In mahotas, I use C++ templates to achieve a similar effect. I don't however, do all combinations. For example erode(image, structuring_element) will convert structuring_element to the type of image. This way only one instance for type is generated (also, structuring_element is guaranteed to be PyArray_CARRAY). structuring_element is often really small, so the time cost is negligable. Similarly, operations on labeled objects [for example, labeled_sum, which gives you the same of pixel values inside each region] require int32 labels, which is what ``label`` returns, but can have anything on the image side (again, only one per type, not an explosion). I think that the size of resulting binaries is quite reasonable as it is most often only an inner loop that gets replicated 6 times or so. My initial variants did generate all combinations and it rapidly became very large (a few MB for morphological functions, for example). My two euro-cent, Luis PS: support for multiple types without a performance cost was one of the original reasons why I rejected Cython in favour of C++ (the other was that, when I started mahotas, Cython was still Pyrex and still a major pain for users to install). On Friday, October 12, 2012 11:05:54 PM UTC+1, Stefan van der Walt wrote:

On Fri, Oct 12, 2012 at 10:38 AM, Johannes Schönberger <hannessch...@gmail.com <javascript:>> wrote:

...

Are those binaries really that huge? I just tested this locally and the binaries were larger, but imho not too big. The question is who actually cares about a few extra KB disk space taken by a binary?

In SciPy, we were looking at huge files, much longer compilation times, increased memory use, etc. Maybe you can compare these factors and see how it goes? I don't know if it can be avoided, on principle, since you basically have to generate separate functions for each type combination, which makes things explode combinatorially.

Stéfan