[SciPy-dev] Suppressing of numpy __mul__, __div__ etc

[Charles R Harris]

On Thu, Dec 17, 2009 at 5:54 PM, Charles R Harris <charlesr.harris at gmail.com
> wrote:

>
>
> On Thu, Dec 17, 2009 at 4:35 PM, Charles R Harris <
> charlesr.harris at gmail.com> wrote:
>
>>
>>
>> On Thu, Dec 17, 2009 at 2:27 PM, James Bergstra <james.bergstra at gmail.com
>> > wrote:
>>
>>> I develop another symbolic-over-numpy package called theano, and
>>> somehow we avoid this problem.
>>>
>>> In [1]: import theano
>>>
>>> In [2]: import numpy
>>>
>>> In [3]: numpy.ones(4) * theano.tensor.dmatrix()
>>> Out[3]: Elemwise{mul,no_inplace}.0
>>>
>>> In [4]: theano.tensor.dmatrix() * theano.tensor.dmatrix()
>>> Out[4]: Elemwise{mul,no_inplace}.0
>>>
>>> In [5]: theano.tensor.dmatrix() * numpy.ones(4)
>>> Out[5]: Elemwise{mul,no_inplace}.0
>>>
>>>
>>> The dmatrix() function returns an instance of the TensorVariable class
>>> defined in this file:
>>> http://trac-hg.assembla.com/theano/browser/theano/tensor/basic.py#L901
>>>
>>> I think the only thing we added  for numpy was __array_priority__ =
>>> 1000, which has already been suggested here.  I'm confused by why this
>>> thread goes on.
>>>
>>>
>> Hmm,
>>
>> That does seem to work. I wonder if it is intended or just fortuitous, the
>> documentation says:
>>
>> The __array_priority__ attribute
>>>
>>> __array_priority__
>>> This attribute allows simple but flexible determination of which sub-
>>> type should be considered “primary” when an operation involving two or more
>>> sub-types arises. In operations where different sub-types are being used,
>>> the sub-type with the largest __array_priority__ attribute will determine
>>> the sub-type of the output(s). If two sub- types have the same
>>> __array_priority__ then the sub-type of the first argument determines
>>> the output. The default __array_priority__ attribute returns a value of
>>> 0.0 for the base ndarray type and 1.0 for a sub-type. This attribute can
>>> also be defined by objects that are not sub-types of the ndarray and can be
>>> used to determine which __array_wrap__ method should be called for the
>>> return output.
>>>
>>
>> Which doesn't seem directly applicable. Perhaps the documentation is
>> wrong, the last sentence is a bit confusing.
>>
>>
> OK, looks intended:
>
>     /*
>      * FAIL with NotImplemented if the other object has
>      * the __r<op>__ method and has __array_priority__ as
>      * an attribute (signalling it can handle ndarray's)
>      * and is not already an ndarray or a subtype of the same type.
>      */
>
> This is in ufunc_object.c. However, it doesn't works for general ufuncs,
> i.e.,  np.multiply(a,b) isn't the same as "a * b"
>
>
What makes this confusing is that it is in the wrong place. This sort of
behaviour should be enforced in multiarray, not in the ufunc object.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091218/5e4f2010/attachment.html>