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) > > > 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. 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? 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. Aaron Meurer > > There are borderline questions, like "is this element invertible?" or "is > this relation trivial in the group we are studying?". > > I guess the reason why I did not consider this dichotomy so far is that > groebner basis computations seem, to me, to very much fall in the second > category (being about elements, not the whole ring). > > > Actually, thinking about it, this discussion does not seem terribly useful. > Either approach can emulate the other easily (one can define R.mul(a, b) to > return a*b, and one can define a*b to return R.mul(a,b), assuming elements > know to which ring they belong). How can one approach have a decisive > advantage over the other if they are almost equivalent? > > >> Obviously, both approaches discussed here are approaches which *work*. >> However, we should also choose the approach which is correct and >> corresponds to the entities in the situation we want to model. >> >> I don't want to sound obstinate, really :-) It's just that I have yet >> to see a solid argument which would prove my position wrong or >> inefficient. >> >> 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. > -- 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.
