Design #483

Unique copies of rings in CoCoA-5

Added by John Abbott about 4 years ago. Updated about 4 years ago.

CoCoA-5 function: new
Target version:
Start date:
19 Mar 2014
Due date:
% Done:


Estimated time:
Spent time:


If a user creates the same ring twice, should he get the exact same ring?

Use QQ[x];
f := x;
Use QQ[x];
g := x;
f+g; --> should this work?

Currently, CoCoA-5 creates two distinct but "identical" rings, so f+g produces a MixedRings error. This is quite close to a nasty surprise.

Related issues

Related to CoCoALib - Feature #482: Unique copies of rings -- smart ctorIn Progress2014-03-19

Related to CoCoA-5 - Feature #274: InputForm for output readable as inputIn Progress2012-06-20

Related to CoCoA-5 - Feature #7: Automatic mapping between (some) ringsIn Progress2011-10-20

Related to CoCoALib - Feature #281: Store unique copy of FF(p) in GlobalManagerNew2012-12-03

Related to CoCoALib - Feature #390: Store unique copy of QQ[t_1..t_n] (RingQQt) in GlobalManagerClosed2013-07-23

Related to CoCoA-5 - Feature #18: Printing matrices: I/O unified style for CoCoA-5?Closed2011-11-02

Related to CoCoA-5 - Support #548: Printing rings with IDClosed2014-05-06

Related to CoCoA-5 - Design #646: Unique copies of free modules?New2014-11-10


#1 Updated by John Abbott about 4 years ago

Conceptually this issue seems practically identical to #482.

Yet, I think they are slightly independent: if CoCoALib makes unique copies of rings then CoCoA-5 pretty much has no choice, but CoCoA-5 could make unique copies even if CoCoALib does not: e.g. CoCoA-5 maintains a global registry of rings, but CoCoALib does not.

To facilitate the porting of CoCoA-5 code into CoCoALib it is probably best that two adopt the same policy.

#2 Updated by Anna Maria Bigatti about 4 years ago

  • Target version set to CoCoA-5.1.0 Easter14

#3 Updated by John Abbott about 4 years ago

  • Target version changed from CoCoA-5.1.0 Easter14 to CoCoA-5.?.?

Also available in: Atom PDF