On Sat, Mar 31, 2012 at 2:04 PM, Tom Bachmann <[email protected]> wrote: > On 31.03.2012 20:19, Aaron Meurer 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) >> >>> >>> >>> 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. >> > > Well, a groebner basis computation certainly *is* an "element-computation" > (isn't it?). And that's what this proposal is actually about... > > >> 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)>"? > > > "Nitpick": they are not ... (e.g. QQ<sqrt(6)> is a 2-dimensional vector > space over QQ, whereas QQ<sqrt(2), sqrt(3)> is 4-dimensional). > > Your basic point is valid, of course.
Oh, I guess it's been too long :) I think I meant sqrt(2) + sqrt(3). Aaron Meurer > > >> 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. > -- 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.
