Le dimanche 01 avril 2012 à 18:54 +0300, Sergiu Ivanov a écrit : > On Sat, Mar 31, 2012 at 10:19 PM, Aaron Meurer <[email protected]> wrote: > > On Sat, Mar 31, 2012 at 11:22 AM, Tom Bachmann <[email protected]> wrote: > >> Obviously I don't want to sound obstinate either, but I really cannot > >> imagine you find a majority on this list which prefers to write R.mul(a, b) > >> instead of a*b, whatever the argument for or against. > > > > The way I see it, if a and b are elements of the ring R, then the > > information for multiplication is in those elements (via the > > superclass or whatever), so a*b should be no different than R.mul(a, > > b). The issue is when they are elements of two different rings, and > > you need to coerce one to the other. You then create coercion rules > > what are pragmatically useful. For example, an element of ZZ times an > > element of QQ give an element of QQ. You could also define that to > > give an error, unless the element of QQ is also an integer, but this > > is not very useful. If you do really want this, than you can > > specifically apply ZZ.mul(a, b) > > It should be possible to have operation-unaware classes for elements > and operation-aware rings, and then define simple ring-aware wrappers > for elements which will take care of making a*b and R.mul(a,b) > equivalent. > > I'm not sure about how well Python inlines functions, but if does a > decent job of this, the code a*b will be directly reduced to > R.mul(a,b) and thus no run-time performance penalty will follow.
Python doesn't inline functions. It's a rather fundamental part of its semantics that makes tracebacks and debuggers possible. PyPy's JIT compiler detects cases where inlining is possible without affecting the behaviour of the program, but CPython (the standard implementation of Python) doesn't have a JIT, so it never inlines. Besides, how can a and b know which they belong to? This would require having several different versions of e.g. sqrt(6): one in QQ[sqrt(6)], one in QQ[sqrt(2), sqrt(3)], one in RR, one in CC, ... IIUC, Sage does exactly that, but it feels profoundly wrong. It should clearly be the other way round: R.mul(a, b) should be defined as a*b. And since we'd like ring operations to be symbolic objects, we should even have R.mul = Lambda((x, y), x*y). > I still advocate for keeping elements and operations separate simply > because there is no such connection between elements and operations in > algebraic structures. > > >> On 31.03.2012 16:05, Sergiu Ivanov wrote: > >>> > >>> Summarising: when you work in concrete rings (integers, reals, etc.) > >>> and focus on elements thereof, the "real" stuff is indeed in elements. > >>> However, if the focus is on the rings themselves, the situation is > >>> utterly different. Consider, for example, a quite real task of > >>> deciding whether a ring with a given set of generators is commutative > >>> or not. The focus is on rings. > >>> > >> > >> Maybe this is the crux of the matter. Some questions inherently deal with > >> the *whole* algebraic structure (is this ring commutative? is it a field?). > >> The elements themselves don't really enter. Other questions deal mostly > >> with > >> elements (is this polynomial irreducible? do these polynomials generate a > >> radical ideal?). > > > > Right, I think the thing being discussed here is a completely > > different sort of computations. They are more inline with the sort of > > things being discussed about groups. > > Yes, absolutely. > > > So far, the only useful thing we've done with rings are with the > > elements, i.e., the polys. But doing stuff like computing things > > based on generators could be useful too. The question is, would the > > two ever mix? In other words, is there any reason to use the same > > class for both viewpoints? > > Please note that I do not by any means suggest abolishing the Ring > class in polys for now. I am only talking of renaming it to > RingDomain. > > I think that the currently existing Ring class could be subclassed > from the Ring class I am suggesting, and it should work with > operation-aware elements. Thus, it seems to me, we are able to deal > with the overlap, minimise the number of changes to polys, and leave > the Ring class I am suggesting unconstrained. > > > An interesting place where this might apply could be algebraic fields > > (or rings). How do we represent things like "QQ<sqrt(6)> is > > isomorphic to QQ<sqrt(2), sqrt(3)>"? Do we want to be able to > > represent symbolic things like "QQ<sqrt(x*y)> is isomorphic to > > QQ<sqrt(x), sqrt(y)>"? (answer: yes, those are just algebraic > > functions instead of algebraic numbers). Some of this is already > > implemented, though I don't know enough about the implementation yet > > to say much. > > I plan to write one more proposal shortly; it's going to be about my > pet idea -- the category theoretical module. I expect such > isomorphisms to be able to be naturally expressed via category > theoretic diagrams. > > I guess it doesn't make much sense right now, but I hope to have the > proposal ready in a couple days. > > Sergiu > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
