On 11/06/2018 20:04, Nils Bruin wrote:
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.

Localization is not the only situation where plenty of elements are
invertible. The ring of integers of a number field is another relevant
example.

Moreover, I found such complicated (and not completely clear) rule more
confusing than what I suggested: a/b go to the fraction field as soon
as the parent is an integral domain. For internal division use //.

(Note that the ring of integers does not follow this rule since a//b
also returns something in the field but we might want to change that)

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.

I definitely share Nils worries about coercions being not compatible
with binary ring operations +,-,*,/.

Vincent

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

Reply via email to