do not use identical var names when constructing rings

[rwst]

novoselt in comment 17 of #13360:

By the way, I think that this is a bug:

sage: QQ["t"]["t"]
Univariate Polynomial Ring in t over Univariate Polynomial Ring in t over Rational Field

Nobody in mathematics uses the same variable in the same expression with the same meaning, so there is no reason to support it. Moreover, this may indicate a logical error and a user would appreciate catching it. So I think that constructions that "add names" should check that they are absent in the base ring. This way it would be prohibited to create SR["t"], but all polynomials can remain coercible to SR.

I suppose adding such a check is also not extremely difficult, but care should be taken when constructing polynomials "for internal purposes". There should be some standard way to get from a ring a name that can work as a "new name". And it should raise an exception for SR.

I also think that for any element of any ring we should have R(str(f)) == f which is impossible to hope for if we do not insist on distinct names for generators.

I think it's not the worst solution to silently change ["t"]["t"] to ["t1"]["t2"] automatically.

CC: @novoselt

Component: commutative algebra

Issue created by migration from https://trac.sagemath.org/ticket/16447

[nbruin]

comment:1

Consider

R=QQ['t']
S=R['t']

If this results in S==Q['t1']['t2'] then S.basering() != R, and in fact R will not coerce into S. That's really bad. Print names of generators are part of the mathematical identity of an object in Sage. We can't change what is supplied, since you wouldn't be producing what is asked for.

[tscrim]

comment:2

I agree with Nils on this, the silent changing of the base ring will cause problems. However I can see (potential?) coercion confusion, so my thought would be to raise an error (or warning?) anytime we are creating a variable name that exists in the base ring. We also have to make sure we handle cases like this too:

QQ['t']['s']['t']

So note that the first t is not one of the direct variables when adjoining the second t.

[novoselt]

comment:3

Definitely no to automatic change of names: it can have any sense only when working interactively when the user can notice a substitution. If it is in the code, the name supplied to the constructor may be used later in exactly the same form rather than requesting generators of the new ring.

I also want to point out that SR["t"] is still a useful construction, at least I have found it useful and I think some other people as well. So prohibiting it without a clear replacement is not ideal. And a clear replacement would be, I think, a symbolic ring with either whitelisted or blacklisted names.

[rwst]

comment:4

The SR issue is different from this commutative algebra ticket. There are also too many cryptic tracebacks in Sage IMO, so I think a warning should be it.