Opened 7 years ago
Last modified 7 years ago
#16447 new defect
do not use identical var names when constructing rings
Reported by: | rws | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | sage-6.4 |
Component: | commutative algebra | Keywords: | |
Cc: | novoselt | Merged in: | |
Authors: | Reviewers: | ||
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
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 FieldNobody 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 toSR
.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.
Change History (5)
comment:1 Changed 7 years ago by
comment:2 Changed 7 years ago by
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
.
comment:3 Changed 7 years ago by
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.
comment:4 Changed 7 years ago by
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.
comment:5 Changed 7 years ago by
- Milestone changed from sage-6.3 to sage-6.4
Consider
If this results in
S==Q['t1']['t2']
thenS.basering() != R
, and in fact R will not coerce intoS
. 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.