On Monday, June 11, 2018 at 10:30:42 AM UTC-7, David Roe wrote: > > The standard that I would propose is the following: > 1. If R has been constructed as a localization (namely, if the > construction() method returns some kind of localization functor) then the > result of a/b will lie in R. If b is not invertible in R (like 0 in a > field), raise an error. This error can provide instructions on using the > fraction field if R is an integral domain. > 2. Otherwise, if R is an integral domain, a/b will live in the fraction > field of R. > 3. Finally, if R is not an integral domain, a/b will live in R, raising an > error if b is not a unit. > And you would exclude p-adics and power series from this because they are obtained via completion?
On the face of it, this seems to make sense: if someone goes out of their way to invert some elements but not all, then he/she probably doesn't want those other elements to be inverted automatically. You are introducing some non-commutativity into the coercion graph that way, though. If we have R=LaurentPolynomialRing(QQ,'x') Qx.<x>=QQ[] then with your proposal we'd have sage: parent((x+1)/x) Fraction Field of Univariate Polynomial Ring in x over Rational Field sage: parent(R(x+1)/x) Univariate Laurent Polynomial Ring in x over Rational Field [as we have now] but sage: parent(x/(x+1)) Fraction Field of Univariate Polynomial Ring in x over Rational Field sage: parent(R(x)+x) Univariate Laurent Polynomial Ring in x over Rational Field sage: parent(R(x)/(x+1)) <ERROR> thus, we see that sage (rightly) has the canonical embeddings QQ[x] subset QQ[x,x^(-1)] subset QQ(x) but coercion into the middle set might prevent operations from succeeding. On the user level I don't think there is anything wrong with that: it's basically what the user asks for. As always, though, the real problems with coercions occur when they happen some levels deeper, i.e., if we have other objects defined over QQ[x], QQ[x,x^(-1)] and QQ(x). I think a decision like this will prevent Laurent polynomials from being a "fully supported base ring", in the sense that objects based on top of it will behave in unexpected ways. That might just be fine, though. You might want to ask some toric geometers if they are going to be happy with this, though. > Of course, currently the construction method for Laurent polynomials is a > special LaurentPolynomialFunctor, but this can be changed. I think an > approach that treats localizations differently is important if we want to > support other kinds of localizations in a reasonable way. > David > > >>> > I think that any comparison to the integers is a bit unfair given that >>> ZZ >>> > and QQ are generally very good with ducktyping and there is no natural >>> way >>> > to create the inverse of the variables (i.e., what makes them Laurent >>> > polynomials) other than by division or exponentiation. >>> >>> "natural" sounds strange in that context. As already mentioned there is >>> >>> 1 // x >>> >>> to get the inverse of x. And x.inverse_of_unit() also does the job. >>> >> >> Nobody is going to want to type inverse_of_unit() when they want x^-1; >> plus I would never have thought of that to get x^-1. >> >> I had the same first thought as Jeroen with 1 // x == 0, but then I >> thought in terms of quo_rem, and 1 // x should return the quotient, which >> in this case is x^-1. However, it would take a little bit for me to realize >> this is what I have to do. >> >>> >>> Though, close to what Nils talked about, there is no straight >>> method for "internal division or raise error". >> >> >> I thought inverse_of_unit() did this? >> >> Best, >> Travis >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sage-devel" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to sage-devel+...@googlegroups.com <javascript:>. >> To post to this group, send email to sage-...@googlegroups.com >> <javascript:>. >> Visit this group at https://groups.google.com/group/sage-devel. >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
