Dag Sverre Seljebotn wrote:
> Roland Schulz wrote:
>>
>> On Wed, May 13, 2009 at 3:16 AM, Dag Sverre Seljebotn
>> A) There's a clash with existing semantics to be resolved. For instance
>> if you have a NumPy "matrix" instance, then * does matrix multiplication
>> instead, and just implementing this now would break code.
>>
>> http://wiki.cython.org/enhancements/buffersyntax
>> http://thread.gmane.org/gmane.comp.python.numeric.general/28439
>>
>> contains my thoughts on how this could be resolved. I'll use this syntax
>> below.
>>
>>
>> I think this could solved by allowing to define custom mapping of
>> operators/methods of python types/classes to C functions. With that one
>> could define that for Numpy ndarray the element wise multiplication is
>> used and for NumPy matrix the matrix multiplication is used. And both
>> could be translated into calls of Eigen or some other vector library.
>>
>> This would allow to directly transform normal NumPy, which tries to
>> avoid using loops, into highly optimized C with SSE without any
>> intermediate buffers.
>
<SNIP>
> Another perspective is that it is nice to be able to have a consistent
> way of working with any Python 3 buffer. This advantage is not obvious
> yet as there are very few such buffers, but I think in time Python might
> contain more and more of what NumPy does now (i.e. the functions in the
> math module might become "ufuncs" able to operate on any PEP 3118 buffer
> and so on).
Note that one could implement this in "shadow module" mode as well. I.e.
@cython.locals(arr=cython.int[:])
def f(arr):
return arr * arr + 2
could be made to work in pure Python mode by coercing the argument to an
appropriate NumPy subclass emulating the explicit buffers.
So I think it is primarily about what kind of syntax it is natural to
work with etc; the one "transparently" optimizing some parts of what one
is used to writing in Python, or the one shouting "syntax error"
whenever you do something which is not an optimized, fast operation.
I find I now (after nearly a year) wish I had gone for the latter
instead :-) as users are still caught by surprise that e.g. "arr[2][3]"
isn't as fast as "arr[2,3]", but there's no compiler complaints, and so on.
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
