On Wed, Jul 14, 2010 at 11:23 AM, Dag Sverre Seljebotn
<[email protected]> wrote:
> 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).
That was my first thought too--what advantage is there to inlining C
into the mix? Fortran I can see more of a usecase for, though even
then I hope that Cython will be able to handle most of those usecases
as well.
Though I can see the advantages of weave, I think it'd be even better
if one didin't have to switch back and forth between completely
unrelated syntaxes/types/etc. Do people use weave because there are
certain things that are more natural to express in Fortran (and/or C),
or is it primarily a convenient way to inline compiled code? Still
waiting for someone to put up a wiki page on what they like from weave
and what should go into Cython.
I think an
@cython.compile
def foo(...):
...
could go a long way here, and even
...
cython.eval("""
[valid cython code]
""")
could have its merits too (though it's not near as clean.
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
