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

[Sebastian Walter]

1) From an abstract point of view, oofun should be a data type.
And the container of choice would be a numpy.array of dtype ofun, not
of dtype object.

so array([1,2,3],dtype=float) * oofun(2) should return
array([2,4,6],dtype=returntype(oofun,float))

I.e. there should be a way to implement new data types.
Maybe add something like

class oofun:
    dtype = True

then ndarray.__mul__ would call appropriate interface functions
provided by the oofun class.
I think that's what josef suggested in an earlier post.

2) I understand that the current behaviour is not nice, e.g. for array
* matrix the matrix.__rmul__ operator should be called.
In fact, I run into the same problem a lot.

I think the only special case of interest are objects that are
themselves containers. E.g. matrix is a container, lil_matrix is a
container, etc.

ndarray knows how to treat some containers, e.g. lists.
The question is, what should ndarray do when it encounters an object
that is a container it doesn't know how to handle.

Wouldn't the following make sense:

When ndarray.__mul__(self, other) is called, and other is a container,
it should simply check if it knows how to handle that container.
If ndarray doesn't know, it should call the other.__rmul__ and hope
that `other` knows what to do.

E.g.

class matrix:
    iscontainer = True
    ....


class ndarray:

    def __mul__(self, other):
       if other.iscontainer:
           if not know_what_to_do_with(other):
               other.__rmul__(self)

      else:
          do what is done now: treat other as dtype=object


then array * matrix
would call the ndarray.__mul__ operator
it then realizes that matrix is a container but ndarray doesnt know
what to do with it. It would therefore call matrix.__rmul__

If other is not a container it is treated as object and we would get
the current behaviour. This would allow to stay backward compatible.





On Thu, Dec 17, 2009 at 10:45 AM, Dag Sverre Seljebotn
<dagss@student.matnat.uio.no> wrote:
> Sebastian Walter wrote:
>> I have also implemented/wrapped various automatic differentiation
>> tools in python
>> (http://github.com/b45ch1/algopy , http://github.com/b45ch1/pyadolc,
>> http://github.com/b45ch1/pycppad if someone is interested)
>> and I have also come across some numpy glitches and inconsistencies.
>>
>> However, this particular problem I have not encountered. I'm not sure
>> I understand the rationale why an expression like numpy.array([1,2] *
>> oofun(1) should  call the oofun.__rmul__ operator.
>> Hence, I'm a little sceptical about this enhancement.
>>
>> What is wrong with the following implementation? It works perfectly fine...
>>
> Well, if you feel that way, then simply don't use this feature. This
> just leads to more flexibility for writers of libraries which depend on
> NumPy.
>
> The suggestion isn't really inconsistent with Python. Even if it is true
> that left-mul takes precedence in Python, it is NOT common that an
> object handles all arithmetic operations whether they make sense or not. So
>
> 2 * MyClassWhichKnowsAboutPythonIntegers()
>
> works, because the "2" doesn't try to do anything and rmul is called!
> NumPy is special because rmul never gets called with NumPy arrays, which
> can be quite inconvenient at times.
>
> Dag Sverre
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev@scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>