Re: the "3*x works w/o __rmul__" bug
Hi all, I just wanted to add a small comment on this discussion, which I'd been following via the newsgroup mirror. Python is picking up a lot of steam in the scientific computing community, and in science it is quite common to encounter non-commutative multiplication. Just to remind Guido from his old math days :), even for square matrices, AB!=BA in most cases. The Matrix class supplied with Numpy is one example of a widely used library which implements '*' as a non-commutative multiplication operator. From what I've read, I realize that this is quite a subtle and difficult bug to treat. I just wanted to add a data point for you folks to consider. Please don't dismiss non-commutative multiplication as too much of an obscure corner case, it is a daily occurrence for a growing number of python users (scientists). Thanks, Fernando.
On Tuesday 28 October 2003 08:24 pm, Fernando Perez wrote:
Hi all,
I just wanted to add a small comment on this discussion, which I'd been following via the newsgroup mirror.
Thanks for your comments! I didn't even know we HAD an ng mirror...
Python is picking up a lot of steam in the scientific computing community, and in science it is quite common to encounter non-commutative multiplication. Just to remind Guido from his old math days :), even for square matrices, AB!=BA in most cases. The Matrix class supplied with
Yes, of course, you're right. However, the most specific problem is: do you know of ANY use cases where A*x and x*A should give different results, or the former should succeed and the latter should fail, *when x is an integer*? If you can find any use case for that, even in an obscure branch of maths, then clearly the urgency of fixing this bug goes WAY up. Otherwise -- if having the problem specifically for an integer x ONLY should not affect anything -- the bug is basically only going to show up in software that's under development and not yet completed, or else not fully correct. I _still_ want to fix it, but... the urgency of doing so is going to be different, as I'm sure you'll understand! Thanks again for your help -- we DO need to hear from users!!! Alex
Alex Martelli wrote:
On Tuesday 28 October 2003 08:24 pm, Fernando Perez wrote:
I just wanted to add a small comment on this discussion, which I'd been following via the newsgroup mirror.
Thanks for your comments! I didn't even know we HAD an ng mirror...
Via gmane news, it works quite well in fact. I typically follow python-dev there, and only subscribe occasionally if I need to say something.
Yes, of course, you're right. However, the most specific problem is: do you know of ANY use cases where A*x and x*A should give different results, or the former should succeed and the latter should fail, *when x is an integer*?
If you can find any use case for that, even in an obscure branch of maths, then clearly the urgency of fixing this bug goes WAY up.
Well, I'm not a mathematician myself, but I did ask two friends and neither of them could think of such a case quickly (they're applied people, though, we need to ask someone doing abstract algebra :) But I think I can see a 'semi-reasonable' usage case. Bear with me for a moment, please. Suppose A is a member of a class representing a non-linear operator which acts on functions f, such that in particular: A(x*f) != x*A(f) for x an integer. Now, if for some reason I decide to implement the 'application of A', which in the above I represented with (), with '*', the bug you mention does surface, because then: A*x*f != x*A*f Or does it? The left-right order of associativity plays a role here also, and I don't know exactly how python treats these. Granted, this example is somewhat contrived. Here, using __call__ for application would be more sensible, and the associativity rules may still hide the bug. Using '*' for application is not totally absurd, because if you are using finite matrix representations of your operators and functions, then in fact operator-function application _does_ become multiplication in the finite-dimensional vector space. But it _suggests_ a possibility for the bug to surface. At the same time, it also shows that 'really reasonable' uses will probably not easily expose this one. The one idea which I think matters, though, is the following: since in python we can't define new operators, in specific problem domains the existing ones (such as '*') may end up being reused in very unconventional ways. So while I can't think now of a non-commutative integer*THING multiplication, I don't see why someone might not build a THING where '*' isn't really what we think of as 'multiplication', and then the bug matters. In the end, I'd argue that it would be _nice_ to have it fixed, but I understand that with finite developer resources available, this one may have to take a back seat until someone can show a truly compelling case. Perhaps I'm just not imaginative enough to see one quickly :)
Thanks again for your help -- we DO need to hear from users!!!
No problem, thanks for being receptive :) Best, f
Fernando Perez wrote:
On Tuesday 28 October 2003 08:24 pm, Fernando Perez wrote:
I just wanted to add a small comment on this discussion, which I'd been following via the newsgroup mirror. Thanks for your comments! I didn't even know we HAD an ng mirror... Via gmane news, it works quite well in fact. I typically follow
Alex Martelli wrote: python-dev there, and only subscribe occasionally if I need to say something.
Just FYI gmane provides two-way access via nntp. This message is a confirmation. :) Mike
participants (3)
-
Alex Martelli -
Fernando Perez -
Mike Rovner