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. 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.
