On Wed, Sep 7, 2011 at 9:34 AM, Simon King <simon.k...@uni-jena.de> wrote: > Hi William > > On 7 Sep., 17:36, William Stein <wst...@gmail.com> wrote: >> Simon, I agree with you. The function "QuotientRing" should be >> improved so that it works like the functor, e.g,. calls the >> ".quo(...)" method if it exists. > > quo, quotient and quotient_ring are defined for sage.rings.ring.Ring. > So, the existence of a ".quo()" method is granted for usual rings. And > with #11068, the quo[tient[_ring]] methods will also be available > from the category of rings, so that it is also available for matrix > algebras. > > The default for .quotient() is to call QuotientRing. But I guess, > instead of that, the QuotientRing should call the .quotient() method, > because any ring should know what class its quotients belong to. > > A related question: Should quotient rings be unique parents? If "yes": > How should equality of quotient rings be defined? > > Currently, the quotient rings are equal if the defining ideals have > the same list of generators. The variable names are *not* considered > in the comparison: > sage: P.<x,y> = QQ[] > sage: I = P*[x,y] > sage: Q1 = P.quo(I,names=['a','b']) > sage: Q2 = P.quo(I,names=['c','d']) > sage: Q1==Q2 > True > > If quotient rings should become unique parents (this is what I hope), > the generator names must be considered, IMHO.
+1 Yes, definitely the generator names should be considered. > Should we preserve the "quick and dirty" approach to test equality of > the generator list of the ideals? Or can we afford to properly test > equality of ideals (via Gröbner bases, if available)? Good question. It seems like we should defer the question to whatever ideal equality testing already does, which is surely equality of ideals. It definitely seems like the "right thing" is to test equality of ideals, but it is potentially very expensive indeed. > My opinion is: R1.quo(I1,names1)==R2.quo(I2,names2) if and only if > R1==R2, I1.gens()==I2.gens() and names2==names2. Testing I1==I2 via > Gröbner bases is too expensive. I'll let you decide, unless anybody else has a strong opinion. > >> In fact, the code in _apply_functor >> in sage/categories/pushout.py (which I had nothing to do with) and the >> code in the QuotientRing function should be refactored so the actual >> construction only involves calling one function that does the work. > > Sounds reasonable. Probably I can fit a new ticket on top of #9138, > rebasing both #10667 and #11068 relative to the new ticket. > > Cheers, > Simon > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
