opinions requested on x + y behaviour for polynomials

[Frédéric Chapoton]

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 ?

[Vincent Delecroix]

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.

[Dima Pasechnik]

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

[John H Palmieri]

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

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]?

[Edgar Costa]

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

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

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.

[Nils Bruin]

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 + x

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

Short version: There are cases where it genuinely doesn't matter what the name of a variable is. It seems wrong to have to do hard work to find an accepted name for something you'd rather leave unnamed.

[Nils Bruin]

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