[Numpy-discussion] New Operators in Python
Colin J. Williams
Sun Mar 25 09:12:54 CDT 2007
Charles R Harris wrote:
> On 3/24/07, *Travis Oliphant* <email@example.com
> <mailto:firstname.lastname@example.org>> wrote:
> Every so often the idea of new operators comes up because of the need to
> do both "matrix-multiplication" and element-by-element multiplication.
> I think this is one area where the current Python approach is not as
> nice because we have a limited set of operators to work with.
> One thing I wonder is if we are being vocal enough with the Python 3000
> crowd to try and get additional operators into the language itself.
> What if we could get a few new operators into the language to help us.
> If we don't ask for it, it certainly won't happen.
> My experience is that the difficulty of using the '*' operator for both
> matrix multiplication and element-by-element multiplication
> depending on
> the class of the object is not especially robust. It makes it harder to
> write generic code, and we still haven't gotten everything completely
> It is somewhat workable as it stands, but I think it would be nicer if
> we could have some "meta" operator that allowed an alternative
> definition of major operators. Something like @* for example (just
> picking a character that is already used for decorators).
> Yes indeed, this is an old complaint. Just having an infix operator
> would be an improvement:
> A dot B dot C
> Not that I am suggesting dot in this regard ;) In particular, it
> wouldn't parse without spaces. What about division? Matlab has both /
> and \ for left and right matrix division and something like that could
> call solve instead of inverse, leading to some efficiencies.
Yes, thanks to a suggestion from Alan Isaac, this was implemented in
PyMatrix (based on numarray and not yet converted to numpy). / served
for one and // for the other.
Regarding an additional multiply operator, I don't see the need for it.
A matrix and and array are similar dut different animals.
> have both dot and tensordot, which raises the problem of interpretation
> when ndim > 2.
> Numpy-discussion mailing list
More information about the Numpy-discussion