[SciPy-dev] Suppressing of numpy __mul__, __div__ etc
Sebastian Walter
sebastian.walter at gmail.com
Wed Dec 16 17:53:16 EST 2009
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...
--------------- start code snippet -----------------
class oofun:
def __init__(self,x):
self.x = x
def __mul__(self, rhs):
print 'called __mul__'
if isinstance(rhs, oofun):
return oofun(self.x * rhs.x)
else:
return rhs * self
def __rmul__(self, lhs):
print 'called __rmul__'
return oofun(self.x * lhs)
def __str__(self):
return str(self.x)+'a'
def __repr__(self):
return str(self)
------------- end code snippet ----------------
--------- output ----------
basti at shlp:~/Desktop$ python live_demo.py
called __mul__
called __rmul__
called __rmul__
called __rmul__
[2.0a 2.0a 2.0a]
called __rmul__
called __rmul__
called __rmul__
[2.0a 2.0a 2.0a]
------------- end output --------------
regards,
Sebastian
2009/12/16 Dag Sverre Seljebotn <dagss at student.matnat.uio.no>:
> Charles R Harris wrote:
>>
>>
>> 2009/12/14 Dmitrey <tmp50 at ukr.net <mailto:tmp50 at ukr.net>>
>>
>>
>>
>> --- Исходное сообщение ---
>> От кого: Charles R Harris <charlesr.harris at gmail.com
>> <mailto:charlesr.harris at gmail.com>>
>> Кому: SciPy Developers List <scipy-dev at scipy.org
>> <mailto:scipy-dev at scipy.org>>
>> Дата: 14 декабря, 20:26:12
>> Тема: Re: [SciPy-dev] Suppressing of numpy __mul__, __div__ etc
>>
>> > --- Исходное сообщение ---
>> > От кого: Charles R Harris <charlesr.harris at gmail.com
>> <mailto:charlesr.harris at gmail.com>>
>> > Кому: SciPy Developers List <scipy-dev at scipy.org
>> <mailto:scipy-dev at scipy.org>>
>> > Дата: 14 декабря, 20:06:46
>> > Тема: Re: [SciPy-dev] Suppressing of numpy __mul__, __div__ etc
>>
>> > I think it should have numpy or ndarray in the name
>> somewhere to indicate
>> > that it is numpy specific. Hmm <looks in thesaurus>, maybe,
>> >
>> > __supercede_ndarray__,
>> > __disallow_ndarray__,
>> > __deny_ndarray__,
>> > __reject_ndarray__,
>> > __refuse_ndarray__,
>> > __exclude_ndarray__,
>> > __reject_ndarray__, ...
>> >
>> > My preference among those would be __deny_ndarray__.
>> >
>> >
>> > But isn't the issue present with numpy matrices or
>> scipy.sparse matrices as
>> > well?
>> > So I guess instead of ndarray another word should be used.
>> >
>>
>> __has_precedence__
>> __is_prior__
>>
>> Chuck
>>
>> N
>> I guess some numpy developers should choose the final name in
>> numpy IRC channel and inform the list (ASAP) about their
>> collective (and hence final) decision. I'm not skilled in English
>> quite enough, but so short names seems too uninformative to me,
>> they will be not used too often so I guess more informative should
>> be preferred.
>>
>>
>> I don't think we should rush this. I'm waiting for more people to
>> weigh in or offer different solutions.
>
> Well, a different solution would be to have a standard with "operand
> precedence", i.e. an integer which could be compared between objects,
> and the highest one wins and gets to decide how the arithmetic operation
> is carried out.
>
> This could be used to simplify NumPy itself. I.e. assign e.g.
> __operand_precedence__ = 0 for ndarray, 100 for matrix, and use it
> internally in NumPy to decide who carries out the operation.
>
> Between other libraries it gets messy to try to figure out what range of
> values to use though. One would really want to be able to make
> statements about a partially ordered set ("I take priority over ndarray;
> a Frobnicator takes priority over me..."), but it's probably way too
> time consuming and complicated.
>
> I like the "precedence" word though. So my suggestions are
> __operand_precedence__ # boolean or integer?
> __numpy_operand_precedence__ # boolean or integer?
> __precedence_over_ndarray__ # bool
>
>
> Dag Sverre
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
More information about the SciPy-Dev
mailing list