42 views

Skip to first unread message

Aug 26, 2023, 3:22:39 AMAug 26

to sage-devel

Dear all,

currently, if x and y are in two different polynomial rings, one cannot add them.

I propose in https://github.com/sagemath/sage/pull/36138 a sketch of changes that would build a common polynomial ring by taking the union of variables. This does not break too many things. Instead many doctests checking for coercion failure now report coercion success. There are still a few problematic things to solve, in particular about infinite polynomials rings.

Please express your opinion about that change of behaviour.

Frederic

Question: what does magma do ?

Aug 26, 2023, 4:52:51 AMAug 26

to sage-...@googlegroups.com

Hi Frederic,

My opinion is that if there is a single non-ambiguous canonical

parent, then yes. In the case of polynomial rings I think that the

priority is to fix the following kind of non-commutativity in coercion

```

sage: cm = get_coercion_model()

sage: cm.common_parent(QQ['x,y'], QQ['y,x'])

Multivariate Polynomial Ring in x, y over Rational Field

sage: cm.common_parent(QQ['y,x'], QQ['x,y'])

Multivariate Polynomial Ring in y, x over Rational Field

```

This concerns also your use case,in what order will you put variables

in the resulting polynomial ring?

Best

Vincent

PS: one also need to pay attention to monomial ordering

> --

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

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/130fadf1-6308-4d6b-8607-a0f6ca22d76bn%40googlegroups.com.

My opinion is that if there is a single non-ambiguous canonical

parent, then yes. In the case of polynomial rings I think that the

priority is to fix the following kind of non-commutativity in coercion

```

sage: cm = get_coercion_model()

sage: cm.common_parent(QQ['x,y'], QQ['y,x'])

Multivariate Polynomial Ring in x, y over Rational Field

sage: cm.common_parent(QQ['y,x'], QQ['x,y'])

Multivariate Polynomial Ring in y, x over Rational Field

```

This concerns also your use case,in what order will you put variables

in the resulting polynomial ring?

Best

Vincent

PS: one also need to pay attention to monomial ordering

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

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/130fadf1-6308-4d6b-8607-a0f6ca22d76bn%40googlegroups.com.

Aug 26, 2023, 10:25:04 AMAug 26

to sage-devel

I don't like this idea - no matter how you try, people will start creating in their code gazillions of implicit rings.

Dima

>

> Frederic

>

> Question: what does magma do ?

>

Aug 26, 2023, 11:51:26 AMAug 26

to sage-devel

In principle it seems okay, but to be honest, I don't think I understand Sage's polynomial rings. It seems like anything goes:

sage: R.<x> = GF(2)[]

sage: S.<x> = R[]

sage: S

sage: R.0 + S.0

x + x

sage: S.<x> = R[]

sage: S

sage: R.0 + S.0

x + x

Why am I allowed to construct S?

With your proposed changes, what happens in the following situation:

sage: T.<x,y> = QQ[]

sage: U.<x,z> = QQ[]

sage: t1, t2 = T.gens()

sage: u1, u2 = U.gens()

Can I now add t1, t2, u1, u2 by automatically creating QQ[x,y,z]?

Do we merge, and therefore identify, QQ[x,y] with QQ[y,x]?

Aug 26, 2023, 12:06:35 PMAug 26

to sage-...@googlegroups.com

Frederic,

Magma is quite pedantic and doesn't let you do that.

> R<x1,x2> := PolynomialRing(Integers(),2);

> S<y1,y2> := PolynomialRing(Integers(),2);

> x1 + y1;

>> x1 + y1;

^

Runtime error in '+': Arguments are not compatible

Argument types given: RngMPolElt, RngMPolElt

> S<y1,y2> := PolynomialRing(Integers(),2);

> x1 + y1;

>> x1 + y1;

^

Runtime error in '+': Arguments are not compatible

Argument types given: RngMPolElt, RngMPolElt

However, I should also point out that Magma has some global rings, e.g., ZZ, QQ, ZZ[x], QQ[x], and thus, one might be misled into thinking that they constructed two different rings:

> R<x> := PolynomialRing(Integers());

> S<y> := PolynomialRing(Integers());

> x eq y;

true

> x + y;

2*y

> S<y> := PolynomialRing(Integers());

> x eq y;

true

> x + y;

2*y

Cheers,

Edgar

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/30f627ea-06b7-4d08-81b6-a20bd14d952an%40googlegroups.com.

Aug 26, 2023, 12:11:07 PMAug 26

to sage-devel

On Saturday, 26 August 2023 at 08:51:26 UTC-7 John H Palmieri wrote:

In principle it seems okay, but to be honest, I don't think I understand Sage's polynomial rings. It seems like anything goes:sage: R.<x> = GF(2)[]

sage: S.<x> = R[]

sage: S

sage: R.0 + S.0

x + xWhy am I allowed to construct S?

Because someone may write a function

def eigenvectors_over_base_field(M):

f = M.charpoly()

rts = f.roots(multiplicities=False)

V = []

for r in rts:

V.append((M-r).kernel().basis())

return V

The charpoly gets produced in M.base_ring()['x']. If you'd execute this code with

k=QQ['x'].fraction_field(); x=k.0

M=matrix([[x,1],[0,x-1]])

and the ring Q('x')['x'] is NOT allowed to exist, you'd get a mysterious error. You'd need rather expensive code that analyses the ring construction to find the required info to generate a variable name that does not clash. And you'd need similarly expensive code to generate the error in the first place.

Aug 26, 2023, 12:22:07 PMAug 26

to sage-devel

On Saturday, 26 August 2023 at 00:22:39 UTC-7 Frédéric Chapoton wrote:

I propose in https://github.com/sagemath/sage/pull/36138 a sketch of changes that would build a common polynomial ring by taking the union of variables. This does not break too many things. Instead many doctests checking for coercion failure now report coercion success. There are still a few problematic things to solve, in particular about infinite polynomials rings.

I think that creating new parents to satisfy coercion is generally not a good idea. It's really a step further than figuring out (canonical) maps between "known" parents (that is, the ones that are directly presented in the context)

Question: what does magma do ?

In magma, variable names are NOT important. They are just for printing. So coercion is not led by variable names at all. That means it's generally more restrictive in what it can do. It also has a concept of "non-global" polynomial rings [the default for multivariate]. So a univariate polynomial in one variable cannot be added to a multivariate polynomial in two variables; not even between QQ['x'] and QQ['x,y']. So sage is already much more permissive. It can do so because generator names are part of the identity of a parent and also to some extent because parents are mostly globally unique. Both of these properties come with a significant price as well (you can't change generator names, or any properties, and you get an extra problem that generator names may be repeated in the tower, which you now either have to deal with or forbid (which is expensive and inconvenient in its own way).

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu