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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4