[SciPy-dev] Suppressing of numpy __mul__, __div__ etc
Sebastian Walter
sebastian.walter@gmail....
Thu Dec 17 07:12:13 CST 2009
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
>
More information about the SciPy-Dev
mailing list