On 07/14/2010 06:01 PM, Kurt Smith wrote: > On Wed, Jul 14, 2010 at 5:15 AM, Fernando Perez<[email protected]> wrote: > >> On Tue, Jul 13, 2010 at 10:30 PM, Kurt Smith<[email protected]> wrote: >> >>> Unfortunately, for some compilers I've used, array expressions like: >>> >>> array1 = array2 + array3**2 >>> >>> Are slower than the 'do' version with explicit indexing -- that is to >>> say, slower than they should be. Apparently the compilers create >>> temporary arrays, exactly analogous to how numpy does it (although >>> many times faster and with more opportunities for optimization). >>> >> as a minor note, blitz++ handles this with expression templates, and >> that's what weave uses for array manipulations. So one gets very >> numpy-like arrays in c++ that have also efficient behavior in many >> expressions. >> >> Not saying that we don't also want 'inline fortran', just that weave's >> inline/blitz support is actually quite powerful. >> > Yes, it is quite powerful. It will take some doing to get equivalent > support for all that weave has to offer. I'm hoping to allow > something like this, modulo syntactic stuff: > > def cy_weave_example(arr): > src = \ > ''' > for(npy_intp i=0; i<arr_shape[0]; i++) { > for(npy_intp j=0; j<arr_shape[1]; j++) { > arr[i,j] = i * j; > } > } > ''' > cyweave.inline(src, ['arr']) > > The "arr[i,j]" syntax will take some work, and I'm still thinking > about it. It's not valid C, obviously. One possibility would be to > do some simple preprocessing to transform into something like > "arr[__2D_idx(i, j, arr_shape[1])]" where "__2D_idx(...)" is a > generated macro which is something like: > > #define __2D_idx(i, j, s1) ((i) * (s1) + (j)) > > If we were to use the C syntax "arr[i][j]", it would require a weave > recompile whenever the shape of "arr" changes, which would be > annoying. The "arr[i,j]" would preserve the array-like feel and would > be doable. Perhaps there are pitfalls in doing a poor-man's bracket > overloading -- I'm certainly open to suggestions. >
Isn't there's enough tools going in this direction already? This would very closely duplicate what is aimed for (or already exists) in Cython, and not be backwards compatible with Weave... As long as it is not something people are already using anyway, why not allow Cython code within the string? I think you can do pretty much the same as what you propose for C currently, and more future possibilities then seem open (such as array expressions/first class arrays). +1 to make Weave with C++ and Blitz run on top of Cython or fwrap, it's always good to consolidate efforts. Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
