Possible new multiplication operators for Python
Hi all, [ please keep all replies to this only on the numpy list. I'm cc'ing the scipy ones to make others aware of the topic, but do NOT reply on those lists so we can have an organized thread for future reference] In the Python-dev mailing lists, there were recently two threads regarding the possibility of adding to the language new multiplication operators (amongst others). This would allow one to define things like an element-wise and a matrix product for numpy arrays, for example: http://mail.python.org/pipermail/python-dev/2008-July/081508.html http://mail.python.org/pipermail/python-dev/2008-July/081551.html It turns out that there's an old pep on this issue: http://www.python.org/dev/peps/pep-0225/ which hasn't been ruled out, simply postponed. At this point it seems that there is room for some discussion, and obviously the input of the numpy/scipy crowd would be very welcome. I volunteered to host a BOF next week at scipy so we could collect feedback from those present, but it's important that those NOT present at the conference can equally voice their ideas/opinions. So I wanted to open this thread here to collect feedback. We'll then try to have the bof next week at the conference, and I'll summarize everything for python-dev. Obviously this doesn't mean that we'll get any changes in, but at least there's interest in discussing a topic that has been dear to everyone here. Cheers, f
On Sat, Aug 16, 2008 at 11:03 PM, Fernando Perez <fperez.net@gmail.com>wrote:
Hi all,
[ please keep all replies to this only on the numpy list. I'm cc'ing the scipy ones to make others aware of the topic, but do NOT reply on those lists so we can have an organized thread for future reference]
In the Python-dev mailing lists, there were recently two threads regarding the possibility of adding to the language new multiplication operators (amongst others). This would allow one to define things like an element-wise and a matrix product for numpy arrays, for example:
http://mail.python.org/pipermail/python-dev/2008-July/081508.html http://mail.python.org/pipermail/python-dev/2008-July/081551.html
It turns out that there's an old pep on this issue:
http://www.python.org/dev/peps/pep-0225/
which hasn't been ruled out, simply postponed. At this point it seems that there is room for some discussion, and obviously the input of the numpy/scipy crowd would be very welcome. I volunteered to host a BOF next week at scipy so we could collect feedback from those present, but it's important that those NOT present at the conference can equally voice their ideas/opinions.
So I wanted to open this thread here to collect feedback. We'll then try to have the bof next week at the conference, and I'll summarize everything for python-dev. Obviously this doesn't mean that we'll get any changes in, but at least there's interest in discussing a topic that has been dear to everyone here.
Geez, some of those folks in those threads are downright rude. Chuck
On Sat, Aug 16, 2008 at 10:22 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Geez, some of those folks in those threads are downright rude.
Python-dev is nowhere nearly as civil as these lists, which I consider to be an asset of ours which we should always strive to protect. In this list even strong disagreement is mostly very well handled, and hopefully we'll keep this tradition as we grow. Python-dev may not be as bad as the infamous LKML, but it can certainly be unpleasant at times (this is one more reason to praise Travis O for all the work he's pushed over there, he certainly had to take quite a few gang-like beatings in the process). No worries though: I'll collect all the feedback and report back up there. Cheers, f
Aside from "more operators needed", is there a consensus view among the developers? Taking a user's perspective, I see a short run and a long run. SR: I am very comfortable with adding dot versions of operators. I am not worried about reversing the Matlab/GAUSS meanings, but if others are very worried, we could append the dot instead of prepending it. LR: It would be great to use unicode math operators. On this issue, Fortress is being foresightful. Accepting the "times" symbol would be a fairly small move for most users, since it is in the Latin 1 extension of ASCII. Cheers, Alan Isaac
On Sun, Aug 17, 2008 at 6:01 AM, Alan G Isaac <aisaac@american.edu> wrote:
Aside from "more operators needed", is there a consensus view among the developers?
I don't think so, but given that pep 225 exists and is fully fleshed out, I guess it should be considered the starting point of the discussion for reference. This doesn't mean that modifications to it can't be suggested, but that I'm assuming python-dev will want that as the reference point. For something as big as this, they would definitely want to work off a real pep. Having said that, I think all ideas are fair game at this point. I personally would like to see it happen, but if not I'd like to see a final pronouncement on the matter rather than seeing pep 225 deferred forever.
Taking a user's perspective, I see a short run and a long run.
SR: I am very comfortable with adding dot versions of operators. I am not worried about reversing the Matlab/GAUSS meanings, but if others are very worried, we could append the dot instead of prepending it.
LR: It would be great to use unicode math operators. On this issue, Fortress is being foresightful. Accepting the "times" symbol would be a fairly small move for most users, since it is in the Latin 1 extension of ASCII.
I'll be sure to list this as part of the received feedback. I'm personally not too crazy about unicode operators (at least not to the extent that Fortress went, where basically a special IDE would be required to write the code in any reasonable scenario). But I'm willing to change my mind, and I'm *definitely* acting as scribe here, so everything that is presented will be reported back. As we get more info I'll start a summary document, which will then be completed with 'live' feedback from the session at scipy next week. Thanks! Cheers, f
Fernando Perez wrote:
For something as big as this, they would definitely want to work off a real pep.
What might be interesting, for those who want to experiment with this syntax, is to take my Python parser for Python (python4ply - http://www.dalkescientific.com/Python/python4ply.html ) and add support for the proposed syntax. It's only a grammar change and it shouldn't be that hard to change the syntax tree so that a proposed "~+" or whatever gets converted to the right method call. Python4ply generates PVM byte code, so the end result is code that works with the existing Python. You could even be adventurous and map things like a \power b into binary operators, perhaps named "__op_power__" It's loads of fun to tweak the grammar. My tutorial even walks through how to add Perl-like syntax for regex creation and match operator, to allow for line in open("python_yacc.py"): if line =~ m/def (?P<name>\w+) *(?P<args>\(.*\)) *:/: print repr($1), repr($args) :)
LR: It would be great to use unicode math operators.
Though if you want to experiment with this .. I make neither guarantees nor warrantees about Unicode support in what I did. I don't even support the encoding hint that Python code can have. Andrew dalke@dalkescientific.com
On Sun, Aug 17, 2008 at 11:10:11AM -0700, Fernando Perez wrote:
LR: It would be great to use unicode math operators. On this issue, Fortress is being foresightful. Accepting the "times" symbol would be a fairly small move for most users, since it is in the Latin 1 extension of ASCII.
I'll be sure to list this as part of the received feedback. I'm personally not too crazy about unicode operators (at least not to the extent that Fortress went, where basically a special IDE would be required to write the code in any reasonable scenario). But I'm willing to change my mind, and I'm *definitely* acting as scribe here, so everything that is presented will be reported back.
I am very much against unicode operators. I can see a huge amount of problems this will generate, for little gain. There are still some possibilities to use a plain ascii character (I can think of '^', '/', '$', '!', althought each one of these might lead to confusion, and they have a feeling of perl). Could we also go for multiple cahracter operators? Anybody care for '.*'? Gaël
Gaël Varoquaux wrote:
Anybody care for '.*'?
That's border-line case, and probably on the bad idea side because 1.*2 already means something in normal Python. If added there would be a difference between 1.*2 and 1 .*2 This problem already exists. Consider
1 .__str__() '1' 1.__str__() File "<stdin>", line 1 1.__str__() ^ SyntaxError: invalid syntax 1..__str__() '1.0'
but it doesn't come up much because it's extremely rare for anyone to call numerical methods directly. Whereas people already write things like "2*x" so writing "2.*x" to mean piecewise but actually get object-wise seems likely. This is why I think being able to write experimental support for new syntax, and gain experience about it's advantages and disadvantages, could be useful and could provide additional sway for python-dev folks. Andrew dalke@dalkescientific.com
On Sun, Aug 17, 2008 at 09:33:33PM +0200, Andrew Dalke wrote:
Gaël Varoquaux wrote:
Anybody care for '.*'?
That's border-line case, and probably on the bad idea side because 1.*2 already means something in normal Python. If added there would be a difference between 1.*2 and 1 .*2
Good point. This was more of a joke than a serious proposition. The joke is that in Matlab, '.*' is a different operator than '*'. Gaël
On Sun, Aug 17, 2008 at 12:14 PM, Gael Varoquaux <gael.varoquaux@normalesup.org> wrote:
On Sun, Aug 17, 2008 at 11:10:11AM -0700, Fernando Perez wrote:
LR: It would be great to use unicode math operators. On this issue, Fortress is being foresightful. Accepting the "times" symbol would be a fairly small move for most users, since it is in the Latin 1 extension of ASCII.
I'll be sure to list this as part of the received feedback. I'm personally not too crazy about unicode operators (at least not to the extent that Fortress went, where basically a special IDE would be required to write the code in any reasonable scenario). But I'm willing to change my mind, and I'm *definitely* acting as scribe here, so everything that is presented will be reported back.
I am very much against unicode operators. I can see a huge amount of problems this will generate, for little gain. There are still some possibilities to use a plain ascii character (I can think of '^', '/', '$', '!', althought each one of these might lead to confusion, and they have a feeling of perl). Could we also go for multiple cahracter operators? Anybody care for '.*'?
Please read the pep first: the proposal is already for multichar operators, and the various alternatives are discussed in detail there. The .OP form is specifically addressed in the pep, so if you want to discuss that one, you need to cover the objections to it already raised in the pep. As I said before, this discussion shouldn't start from a blank slate: consider the pep 225 http://www.python.org/dev/peps/pep-0225/ as the starting point that python-dev will want for any useful discussion. Cheers, f
Gael Varoquaux wrote:
I am very much against unicode operators. I can see a huge amount of problems this will generate, for little gain.
I actually basically like PEP 225, although I find @*, @+, etc more readable, and to provide the right visual emphasis. (Rather than ~*, ~+, etc.) Additionally, I do not think Unicode addresses the problem central to the PEP, as there is as far as I know no standard symbolic distinction between, say, elementwise multiplication and matrix multiplication. So I think the PEP is basically needed (perhaps with @ instead of ~). That said, what kind of problems do you have in mind? Cheers, Alan Isaac PS Here are the core unicode math operators: http://www.alanwood.net/unicode/mathematical_operators.html or if you do not have appropriate fonts you can try http://www.unicode.org/charts/PDF/U2200.pdf
On Sun, Aug 17, 2008 at 04:28:55PM -0400, Alan G Isaac wrote:
That said, what kind of problems do you have in mind?
A lot of software still don't deal well with unicode (wxPython's unicode situation under windows, for instance, in "interesting"). But wht I am most worried about is not being able to enter the symbol, because I am in an editor I don't know, and the symbol is not on my keyboard. This has happened to me more than once with unicode. So I see the losss, and not the gain. I actually think PEP 225 is pretty good. I have not big opinion about "~" vs "@". Gaël
2008/8/18 Gael Varoquaux <gael.varoquaux@normalesup.org>:
I actually think PEP 225 is pretty good. I have not big opinion about "~" vs "@".
Both of these already have meanings ("boolean not" and "decorator"), so it's pretty much a toss-up for me. In a way, the concept of a decorator could still apply: @* takes the function `mul` and returns a new function, array_mul. Cheers Stéfan
On Sun, Aug 17, 2008 at 04:28:55PM -0400, Alan G Isaac wrote:
That said, what kind of problems do you have in mind?
Gael Varoquaux wrote:
wht I am most worried about is not being able to enter the symbol, because I am in an editor I don't know, and the symbol is not on my keyboard. This has happened to me more than once with unicode.
Well anyone who travels ends up dealing with strange keyboards, I suppose, but I would hate for the possibility that someone is in the odd situation of this happening while not having access to the net (and thus to Vim or emacs) dictate the decision on this. That would just not be very forward looking, especially when one can *in this case* always use ``dot`` instead. But we apparently agree that PEP 225 meets the need for a multiplication operator (with either ~ or @). Do you agree with Robert that *only* the multiplication operator is needed? (See my previous post.) Alan
On Tue, Aug 19, 2008 at 1:57 PM, Alan G Isaac <aisaac@american.edu> wrote:
On Sun, Aug 17, 2008 at 04:28:55PM -0400, Alan G Isaac wrote:
That said, what kind of problems do you have in mind?
Gael Varoquaux wrote:
wht I am most worried about is not being able to enter the symbol, because I am in an editor I don't know, and the symbol is not on my keyboard. This has happened to me more than once with unicode.
Well anyone who travels ends up dealing with strange keyboards, I suppose, but I would hate for the possibility that someone is in the odd situation of this happening while not having access to the net (and thus to Vim or emacs) dictate the decision on this. That would just not be very forward looking, especially when one can *in this case* always use ``dot`` instead.
I absolutely agree with Gael here. Using anything besides lower (<128) ascii is imho not wise. Ondrej
On Tue, Aug 19, 2008 at 07:57:45AM -0400, Alan G Isaac wrote:
But we apparently agree that PEP 225 meets the need for a multiplication operator (with either ~ or @). Do you agree with Robert that *only* the multiplication operator is needed? (See my previous post.)
No big opinion on that. Gaël
But would it be not-trivial to enter times ans alike unicode symbols within "normal" text editors? Otherwise it is a compelling proposition at first glance. Nadav. -----הודעה מקורית----- מאת: numpy-discussion-bounces@scipy.org בשם Alan G Isaac נשלח: א 17-אוגוסט-08 16:01 אל: Discussion of Numerical Python נושא: Re: [Numpy-discussion] Possible new multiplication operators for Python Aside from "more operators needed", is there a consensus view among the developers? Taking a user's perspective, I see a short run and a long run. SR: I am very comfortable with adding dot versions of operators. I am not worried about reversing the Matlab/GAUSS meanings, but if others are very worried, we could append the dot instead of prepending it. LR: It would be great to use unicode math operators. On this issue, Fortress is being foresightful. Accepting the "times" symbol would be a fairly small move for most users, since it is in the Latin 1 extension of ASCII. Cheers, Alan Isaac _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Nadav Horesh wrote:
But would it be not-trivial to enter times ans alike unicode symbols within "normal" text editors? Otherwise it is a compelling proposition at first glance.
First, what is a "normal" text editor? Handling utf-8 seems pretty common these days. http://en.wikipedia.org/wiki/Unicode_input There are two separable issues: entry and display. Entry of unicode operators would presumably involve digraphs. http://en.wikipedia.org/wiki/Digraph_(computing) Display seems largely addressed by the STIX fonts: http://www.stixfonts.org/project.html fwiw, Alan Isaac
On Sun, Aug 17, 2008 at 7:01 AM, Alan G Isaac <aisaac@american.edu> wrote:
Aside from "more operators needed", is there a consensus view among the developers?
Taking a user's perspective, I see a short run and a long run.
SR: I am very comfortable with adding dot versions of operators. I am not worried about reversing the Matlab/GAUSS meanings, but if others are very worried, we could append the dot instead of prepending it.
LR: It would be great to use unicode math operators. On this issue, Fortress is being foresightful. Accepting the "times" symbol would be a fairly small move for most users, since it is in the Latin 1 extension of ASCII.
I kinda like the unicode idea because of the current dearth of usable symbols. In fact, my system is already using utf-8. $[charris@f9 ~]$ locale LANG=en_US.utf8 LC_CTYPE="en_US.utf8" LC_NUMERIC="en_US.utf8" LC_TIME="en_US.utf8" LC_COLLATE="en_US.utf8" LC_MONETARY="en_US.utf8" LC_MESSAGES="en_US.utf8" LC_PAPER="en_US.utf8" LC_NAME="en_US.utf8" LC_ADDRESS="en_US.utf8" LC_TELEPHONE="en_US.utf8" LC_MEASUREMENT="en_US.utf8" LC_IDENTIFICATION="en_US.utf8" LC_ALL= And keymaps are not that hard to do in most editors. However... there are various unicode encodings and locales, often indicated by the first few bytes in a file. It's not clear to me that these encodings are universally implemented at this time and I would be loath to depend on them without some testing. Even so, it might be good to reserve a few symbols for future use as operators. The resistance to adding these operators might be less among Python developers because they are less visible, not multicharater, and won't conflict with current python usage. So at the least I think we should try to get some unicode symbols set aside and maybe several years from now we can start using them. Here is an interesting little article on unicode for unix<http://eyegene.ophthy.med.umich.edu/unicode/>. Here are some links to various symbols<http://mindprod.com/jgloss/unicode.html#SYMBOLS>. And here is a bit of unicode just so we can see how it looks for various folks. A = B⊛C Chuck
On Aug 17, 2008, at 9:38 PM, Charles R Harris wrote:
And here is a bit of unicode just so we can see how it looks for various folks.
A = B⊛C
Or write B \circledast C ? (Or \oast?) Try using Google to search for that character. Andrew dalke@dalkescientific.com
On Sun, Aug 17, 2008 at 1:58 PM, Andrew Dalke <dalke@dalkescientific.com>wrote:
On Aug 17, 2008, at 9:38 PM, Charles R Harris wrote:
And here is a bit of unicode just so we can see how it looks for various folks.
A = B⊛C
Or write B \circledast C ? (Or \oast?) Try using Google to search for that character.
That's what I sent, it's in utf-8. I'm thinking the circleddot looks better, but here a few others A = B⊛C #circled asterisk A = B⊙C #circled dot A = B⍟C #circled star A = B⊗C #circled times (tensor) A = B∙C #dot A = B⋆C #star Chuck
On Aug 17, 2008, at 10:35 PM, Christian Heimes wrote:
Andrew Dalke wrote:
Or write B \circledast C ? (Or \oast?) Try using Google to search for that character.
unicodedata.lookup('CIRCLED ASTERISK OPERATOR') '⊛'
I mean, go to Google and search for "⊛". It finds no hits. I didn't even know the name for that character. I had to copy and paste it into a terminal window that didn't understand the encoding, so it gave me "\342\212\233". I then used Google and found a LaTeX page listing octal Unicode escape characters for various LaTeX definitions, those being "\circledast" which has "\oast" as an alias. Those two terms I can search for. Not some sort of unknown-to-me unicode character. Andrew dalke@dalkescientific.com
On Sun, Aug 17, 2008 at 7:03 AM, Fernando Perez <fperez.net@gmail.com> wrote:
Hi all,
[ please keep all replies to this only on the numpy list. I'm cc'ing the scipy ones to make others aware of the topic, but do NOT reply on those lists so we can have an organized thread for future reference]
In the Python-dev mailing lists, there were recently two threads regarding the possibility of adding to the language new multiplication operators (amongst others). This would allow one to define things like an element-wise and a matrix product for numpy arrays, for example:
http://mail.python.org/pipermail/python-dev/2008-July/081508.html http://mail.python.org/pipermail/python-dev/2008-July/081551.html
It turns out that there's an old pep on this issue:
http://www.python.org/dev/peps/pep-0225/
which hasn't been ruled out, simply postponed. At this point it seems that there is room for some discussion, and obviously the input of the numpy/scipy crowd would be very welcome. I volunteered to host a BOF next week at scipy so we could collect feedback from those present, but it's important that those NOT present at the conference can equally voice their ideas/opinions.
So I wanted to open this thread here to collect feedback. We'll then try to have the bof next week at the conference, and I'll summarize everything for python-dev. Obviously this doesn't mean that we'll get any changes in, but at least there's interest in discussing a topic that has been dear to everyone here.
I like that Python is so easy to learn, so I hope no more operators and definitely not unicode operators will be added. And if, then only if they are really needed, which I think they are not. What I like on Python is that I can remember all it's syntax in my memory. The more operators, the more difficult this will be. There is some inconsistency though, for example one can override A() + A(), but one cannot override 1 + 1. This could (should) be fixed somehow. But apart from that, I very much like Python as it is now and I hope it will not become a bloated language. Ondrej
On Sun, Aug 17, 2008 at 17:00, Ondrej Certik <ondrej@certik.cz> wrote:
There is some inconsistency though, for example one can override A() + A(), but one cannot override 1 + 1. This could (should) be fixed somehow.
This is getting off-topic, but I really hope that never changes. The difference between A.__add__ and int.__add__ is that you are defining A. Python defines int. If you mess with fundamental types like that, you will break other libraries and must confine yourself to just code that you've written. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
On Aug 18, 2008, at 12:00 AM, Ondrej Certik wrote:
There is some inconsistency though, for example one can override A() + A(), but one cannot override 1 + 1. This could (should) be fixed somehow.
That will never, ever change in Python. There's no benefit to being able to redefine int.__add__ and doing so will break entirely too many assumptions. Here's one assumption - the C implementation does some simple constant folding:
def f(): ... print 1+1 ... import dis dis.dis(f) 2 0 LOAD_CONST 2 (2) 3 PRINT_ITEM 4 PRINT_NEWLINE 5 LOAD_CONST 0 (None) 8 RETURN_VALUE
With what you want that's not possible. Just think of the implementation difficulty. Are changes on the per-module or per-scope or per-thread level? And performance would be lousy (or require deep inferencing analysis) because every operation in C would need to go through the Python API just in case some fundamental definition like this was changed. Such a language is possible. I wouldn't be surprised if you could do it in Smalltalk and mostly do it in Ruby. But the general belief is that good design follows the "open/closed principle": "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification" - Bertrand Meyer, quoted by http://en.wikipedia.org/wiki/Open/closed_principle In Python, all types are closed for modification, and while classes are open for modification it's highly frowned upon to do so. The name "monkey-patch" sounds somewhat derisive for a reason. Andrew dalke@dalkescientific.com
On Mon, Aug 18, 2008 at 1:50 AM, Andrew Dalke <dalke@dalkescientific.com> wrote:
On Aug 18, 2008, at 12:00 AM, Ondrej Certik wrote:
There is some inconsistency though, for example one can override A() + A(), but one cannot override 1 + 1. This could (should) be fixed somehow.
That will never, ever change in Python. There's no benefit to being able to redefine int.__add__ and doing so will break entirely too many assumptions.
Here's one assumption - the C implementation does some simple constant folding:
def f(): ... print 1+1 ... import dis dis.dis(f) 2 0 LOAD_CONST 2 (2) 3 PRINT_ITEM 4 PRINT_NEWLINE 5 LOAD_CONST 0 (None) 8 RETURN_VALUE
With what you want that's not possible.
Just think of the implementation difficulty. Are changes on the per-module or per-scope or per-thread level? And performance would be lousy (or require deep inferencing analysis) because every operation in C would need to go through the Python API just in case some fundamental definition like this was changed.
Such a language is possible. I wouldn't be surprised if you could do it in Smalltalk and mostly do it in Ruby. But the general belief is that good design follows the "open/closed principle":
"software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification" - Bertrand Meyer, quoted by http://en.wikipedia.org/wiki/Open/closed_principle
In Python, all types are closed for modification, and while classes are open for modification it's highly frowned upon to do so. The name "monkey-patch" sounds somewhat derisive for a reason.
Yeah, I understand the reasoning. My reason is that sometimes you want to do something else on 1/2 rather than to get 0, or 0.5000000. I would like to get my own class called, but if it's again Python, then I am perfectly happy with Python as it is now. No changes needed. Anyway, this is off topic. Ondrej
On Sat, 2008-08-16 at 22:03 -0700, Fernando Perez wrote:
Hi all,
[ please keep all replies to this only on the numpy list. I'm cc'ing the scipy ones to make others aware of the topic, but do NOT reply on those lists so we can have an organized thread for future reference]
In the Python-dev mailing lists, there were recently two threads regarding the possibility of adding to the language new multiplication operators (amongst others). This would allow one to define things like an element-wise and a matrix product for numpy arrays, for example:
http://mail.python.org/pipermail/python-dev/2008-July/081508.html http://mail.python.org/pipermail/python-dev/2008-July/081551.html
It turns out that there's an old pep on this issue:
http://www.python.org/dev/peps/pep-0225/
which hasn't been ruled out, simply postponed. At this point it seems that there is room for some discussion, and obviously the input of the numpy/scipy crowd would be very welcome. I volunteered to host a BOF next week at scipy so we could collect feedback from those present, but it's important that those NOT present at the conference can equally voice their ideas/opinions.
So I wanted to open this thread here to collect feedback. We'll then try to have the bof next week at the conference, and I'll summarize everything for python-dev. Obviously this doesn't mean that we'll get any changes in, but at least there's interest in discussing a topic that has been dear to everyone here.
Cheers,
f
As one of the original author behind the PEP225, I think this is an excellent idea. (BTW, thanks for resurrecting this old PEP :-) and considering it useful :-) :-) ). I think I do not need to speak to much for the PEP, telling that I did not change my mind should be enough ;-)...but still, I can not resist adding a few considerations: Demands for Elementwise operators and/or matrix product operator is likely to resurface from time to time on Python-dev or Python-idea, given that this is a central feature of Matlab and Matlab is a de-facto standard when it comes to numeric-oriented interpreted languages (well, at least in the engineering world, it is in my experience the biggest player by far). At the time of the original discussion on python-dev and of PEP225 redaction , I was new to Python and fresh from Matlab, and the default behavior of elementwise-product annoyed me a lot. Since then, I have learned to appreciate the power of numpy broadcast (Use it extensively in my code :-) ), so the default dehavior do not annoy me anymore... But I still feel that 2 sets of operator would be very useful ( especially in some code which implement directly heavy linear algebra formula), the only thing where my point of view has changed is that I now think that the Matlab way ( defining * as matrix product and .* as elementwise product) is not necessarily the best choice, the reverse choice is as valid... Given the increasing success of Python as a viable alternative, I think that settling the Elementwise operator issue is probably a good idea. Especially as the Python 3000 transition is maybe a good time to investigate syntax changes/extension.
I don't think so, but given that pep 225 exists and is fully fleshed out, I guess it should be considered the starting point of the discussion for reference. This doesn't mean that modifications to it can't be suggested, but that I'm assuming python-dev will want that as the reference point. For something as big as this, they would definitely want to work off a real pep.
Having said that, I think all ideas are fair game at this point. I personally would like to see it happen, but if not I'd like to see a final pronouncement on the matter rather than seeing pep 225 deferred forever.
I agree 100%. Keeping PEP 225 in limbo is the worst situation imho, given that the discussion about elementwise operator (or matrix product) keep showing again and again, having a final decision (even if negative) would be better. And as I said above, I feel the timing is right for this final decision... Best regards, Greg.
On Mon, Aug 18, 2008 at 10:55 AM, Grégory Lielens <gregory.lielens@fft.be>wrote:
On Sat, 2008-08-16 at 22:03 -0700, Fernando Perez wrote:
Hi all,
[ please keep all replies to this only on the numpy list. I'm cc'ing the scipy ones to make others aware of the topic, but do NOT reply on those lists so we can have an organized thread for future reference]
In the Python-dev mailing lists, there were recently two threads regarding the possibility of adding to the language new multiplication operators (amongst others). This would allow one to define things like an element-wise and a matrix product for numpy arrays, for example:
http://mail.python.org/pipermail/python-dev/2008-July/081508.html http://mail.python.org/pipermail/python-dev/2008-July/081551.html
It turns out that there's an old pep on this issue:
http://www.python.org/dev/peps/pep-0225/
which hasn't been ruled out, simply postponed. At this point it seems that there is room for some discussion, and obviously the input of the numpy/scipy crowd would be very welcome. I volunteered to host a BOF next week at scipy so we could collect feedback from those present, but it's important that those NOT present at the conference can equally voice their ideas/opinions.
So I wanted to open this thread here to collect feedback. We'll then try to have the bof next week at the conference, and I'll summarize everything for python-dev. Obviously this doesn't mean that we'll get any changes in, but at least there's interest in discussing a topic that has been dear to everyone here.
Cheers,
f
As one of the original author behind the PEP225, I think this is an excellent idea. (BTW, thanks for resurrecting this old PEP :-) and considering it useful :-) :-) ).
I think I do not need to speak to much for the PEP, telling that I did not change my mind should be enough ;-)...but still, I can not resist adding a few considerations:
Demands for Elementwise operators and/or matrix product operator is likely to resurface from time to time on Python-dev or Python-idea, given that this is a central feature of Matlab and Matlab is a de-facto standard when it comes to numeric-oriented interpreted languages (well, at least in the engineering world, it is in my experience the biggest player by far).
At the time of the original discussion on python-dev and of PEP225 redaction , I was new to Python and fresh from Matlab, and the default behavior of elementwise-product annoyed me a lot. Since then, I have learned to appreciate the power of numpy broadcast (Use it extensively in my code :-) ), so the default dehavior do not annoy me anymore... But I still feel that 2 sets of operator would be very useful ( especially in some code which implement directly heavy linear algebra formula), the only thing where my point of view has changed is that I now think that the Matlab way ( defining * as matrix product and .* as elementwise product) is not necessarily the best choice, the reverse choice is as valid...
Given the increasing success of Python as a viable alternative, I think that settling the Elementwise operator issue is probably a good idea. Especially as the Python 3000 transition is maybe a good time to investigate syntax changes/extension.
I don't think so, but given that pep 225 exists and is fully fleshed out, I guess it should be considered the starting point of the discussion for reference. This doesn't mean that modifications to it can't be suggested, but that I'm assuming python-dev will want that as the reference point. For something as big as this, they would definitely want to work off a real pep.
Having said that, I think all ideas are fair game at this point. I personally would like to see it happen, but if not I'd like to see a final pronouncement on the matter rather than seeing pep 225 deferred forever.
I agree 100%. Keeping PEP 225 in limbo is the worst situation imho, given that the discussion about elementwise operator (or matrix product) keep showing again and again, having a final decision (even if negative) would be better. And as I said above, I feel the timing is right for this final decision...
Tim Hochberg proposed using the call operator for matrix multiplication, i.e., A(B(C)) Which has the advantage of using an existing operator. It looks like function composition, which isn't that far off the mark if matrices are looked at as mappings, but might take a bit of getting used to. Chuck
On Mon, Aug 18, 2008 at 12:21, Charles R Harris <charlesr.harris@gmail.com> wrote:
Tim Hochberg proposed using the call operator for matrix multiplication, i.e.,
A(B(C))
Which has the advantage of using an existing operator. It looks like function composition, which isn't that far off the mark if matrices are looked at as mappings, but might take a bit of getting used to.
It's certainly worth exploring. My personal opinion is that I could just use a single operator for doing matrix multiplication. I don't want to see two variants of every single operator. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
On Mon, Aug 18, 2008 at 12:21, Charles R Harris <charlesr.harris@gmail.com> wrote:
Tim Hochberg proposed using the call operator for matrix multiplication, i.e., A(B(C))
Robert Kern wrote:
It's certainly worth exploring. My personal opinion is that I could just use a single operator for doing matrix multiplication. I don't want to see two variants of every single operator.
User opinion on Tim's proposal: it is not bad, especially if you write A(B)(C) instead of A(B(C)). But in the end I think it looks acceptable only if you do not plan to use matrices much. For teaching purposes: I think it fails for not being explicit enough. I would even prefer A.dot(B).dot(C) for this reason. But I prefer a normal binary multiplication operator! User opinion on Robert's comment: I agree. I use matrix powers and so would feel some loss there, but I could accept say M.pow(n) instead of M**n. So it seems to me, as a user, that the SciPy community should definitely ask for a way to have a distinct matrix multiplication operator. Proposal 1: PEP 225, but *just* for multiplication. Either ~* as in the PEP or @* (which I prefer). (This looks simplest.) Proposal 2: PEP 225 (but maybe using @ instead of ~). Proposal 3: use of a unicode character, perhaps × since it is in the Latin1 extension of ASCII. Proposal 4: user defined operators, perhaps as described in PEP 225. In this case, @dot would be a natural. (This looks most complex but also most powerful.) But is A @dot B really better than say A.dot(B)? Maybe. Propsal 5: use the existing language, either using __call__ as in Tim's proposal or adding a ``dot`` method. Did I miss any? As PEP 225 notes, implementing proposals 1 or 2 does not rule out future interest in proposal 4. Cheers, Alan Isaac
On Tuesday 19 August 2008, Alan G Isaac wrote:
Proposal 1: PEP 225, but *just* for multiplication. Either ~* as in the PEP or @* (which I prefer). (This looks simplest.)
Proposal 2: PEP 225 (but maybe using @ instead of ~).
Proposal 3: use of a unicode character, perhaps × since it is in the Latin1 extension of ASCII.
Proposal 4: user defined operators, perhaps as described in PEP 225. In this case, @dot would be a natural. (This looks most complex but also most powerful.) But is A @dot B really better than say A.dot(B)? Maybe.
Propsal 5: use the existing language, either using __call__ as in Tim's proposal or adding a ``dot`` method.
Did I miss any?
You could abuse Python's current capabilities to create something that looks like proposal 4: C = A *dot* B You would need a helper object named "dot". This has been proposed on the Python-Dev list. I find this kinds of pseudo operator a bit clunky. It might be quite confusing to beginners because really the the "*" operator is invoked twice. The pseudo operator has one nice aspect: It can take additional arguments, which could be nice for the array-of-matrices application. mmul = dot((1,0),(0,1)) C = A *mmul* B -- I'd like PEP 225 to be implemented. The new operators are kind of elegant, and they don't introduce any new concepts. They just introduce a bunch of new special functions. Regards, Eike.
On Mon, 2008-08-18 at 11:21 -0600, Charles R Harris wrote:
Tim Hochberg proposed using the call operator for matrix multiplication, i.e.,
A(B(C))
Which has the advantage of using an existing operator. It looks like function composition, which isn't that far off the mark if matrices are looked at as mappings, but might take a bit of getting used to.
Chuck
This was proposed at the time (It is mentioned in the PEP, but not in details). Clever, but it leads to problems that, imho, makes the new operator superior: -It does not have the classic priority likes normal multiplication, but the presence of parenthesis somewhat mitigates that. Associativity is also not obvious, and mixing with scalar product does not always play nice... -It bares nothing in common with elementwise multiplication, which is bothering if you enjoy orthogonality in language syntax (I do, it help me memorize syntax tremendously), and looks like a (not pretty) trick, especially when teaching the language to beginners -It is not so easy to read: A simple linear algebra formula like system solution could be written x = (A.I)(b), which looks very nice.... [ A.I for lazy inversion of A, evaluated at assignation or as late as possible, to allow for efficient implementation of A * x = b -> x = A.I*b. This lazy operands were considered preferable to left and right division à la Matlab at the time....] Now if you go back to an "heavy" formula from the PEP, it gives, using classic * as matrix multiply and / as right-divide (x/Y = x * Y.I) b = a.I - a.I * u / (c.I + v/a*u) * v / a or with the tilde-operators b = a.I - a.I ~* u / (c.I + v~/a~*u) ~* v ~/ a Using __call__ as matmul: b = a.I - ( (a.I)(u) / (c.I + (v/a)(u)) )(v) / a Still quite nice, but more difficult to parse visually imho... However, as most editors have parenthesis highlighting, it is worth considering, notation can be abused but I agree that if you use spaces and parenthesis cleverly, you can have some nice expressions...Pity the original discussions are not available anymore, it would have been nice to find the original drawbacks mentioned about __call__....
On Tue, 2008-08-19 at 09:49 +0200, Grégory Lielens wrote:
Using __call__ as matmul: b = a.I - ( (a.I)(u) / (c.I + (v/a)(u)) )(v) / a
oups, of course you do not have right-divide in this case, it would thus read b = a.I - (a.I) (u) ( ( c.I + (v)(a.I)(u) ).I ) (v) (a.I) hum, given the amount of re-read I had to do, even with parenthesis-highlighting, I think that visual parsing for complex formula was the biggest drawback ;-)
participants (12)
-
Alan G Isaac -
Andrew Dalke -
Charles R Harris -
Christian Heimes -
Eike Welk -
Fernando Perez -
Gael Varoquaux -
Grégory Lielens -
Nadav Horesh -
Ondrej Certik -
Robert Kern -
Stéfan van der Walt