CoCoA » CoCoALib

At the moment JAA sees no advantage to the current "restrictive" regime for RingElem values.

JAA is not sure if he recalls why we introduced the restriction that a RingElem is eternally associated with a single specific ring. He thinks it may have been vaguely "for reasons of safety".

If we really want to preserve the current restrictions, then JAA notes that it would be technically fairly simple to use a global flag to say whether to be restrictive or permissive.

Since CoCoA-5 does not impose restrictions about "changing ring", it seems hard to justify saying that we need such a restriction in CoCoALib.

What should the following code excerpts do?

Case (A)

RingElem r; // by default an element of RingZZ
r = BigRat(2,1);

Case (B)

RingElem r; // by default an element of RingZZ
r = BigRat(2,3);

Assignment from a BigRat is allowed, and JAA believes it would be inconvenient to forbid it.

Case (A) should surely work; the only question is to which ring r belongs after the assignment (namely ZZ or QQ).
Case (B) might work or might give an error; if it works then after the assignment x can no longer belong to RingZZ, so would presumably belong to RingQQ.

We can make the ring evident by using an explicit constructor like this:

x = RingElem(RingQQ(), BigRat(2,3));

NB we cannot mimic CoCoA-5 because there the type of the value changes from RINGELEM to RAT.

This may not be the correct place, but I wanted to note that until we have automatic conversions (if ever), an equality test between elements of different rings will produce an error!

Here is an example scenario (which is not too far-fetched).

RingElem x(R);
RingElem y(R);
if (x == y) ... // no error here
x = 1;  // to which ring does x belong now?  Either R or ZZ
if (x == y) ... // this will give error if RingOf(x) is not R

This makes me think that (the details of) the current issue are closely related to whether we intend implementing automatic "promotion" of ring elements.

• assignment changes the ring if and only if the assigned value indicates explicitly the ring to use

(i.e. in practice the only possibility currently is when the RHS is itself a RingElem).

• the default ctor for RingElem produces 0 in ZZ
• the rule/guideline in note-4 is good.

We propose implementing in the near future.

If we allow "mixed ring" assignment then we should also allow "mixed ring" swap.

JAA would expect swap to work as if it were implemented like this:

void swap(A,B)
{
  tmp = A;
  A = B;
  B = tmp;
}

John Abbott wrote:

If we allow "mixed ring" assignment then we should also allow "mixed ring" swap.

I agree

Case (A) We have decided that this code:

  RingElem r;

initializes r as being the zero of ZZ

Case (B) What should this code do?

  RingElem r = 3;

Case (C) And what about this?

  RingElem r(3);

If I recall well, the rules of C++ say that cases (B) and (C) either both fail to compile or both succeed (since they trigger effectively the same ctor).

To implement assignment of RingElem which can change the ring, I need to allow ring to be assigned -- currently assignment is disabled.

Any objections to allowing assignment of values of type ring?

JAA does not anticipate any nasty surprises suddenly appearing.

John Abbott wrote:

Any objections to allowing assignment of values of type ring?

ok for me: in fact I had to do use auto-prt tricks to delay initialization somewhere.
I could clean them up :-)

Note that assignment to a RefRingElem cannot change the ring to which it belongs because it may well be a reference to a value inside some other homogeneous structure (e.g. a matrix). Perhaps the choice of name RefRingElem is not ideal any more?

Non homogeneous assignment of RingElem is trickier than I thought (because of the inheritance from RefRingElem).

Currently I'm stuck.

2013-02-18: The problem presented in this post has been resolved by removing the class RefRingElem (see #261)

There is a potential problem with "ring changing" assignment/swap and RefRingElem. The difficulty is highlighted by the following two examples:

(A) This example has been valid for some time, and will print 2

RingElem x(R,1);
RingElem y(R,2);
RefRingElem z(x);
x = y;
cout << "z=" << z << endl;

(B) We get DANGEROUS behaviour if the rings of x and y are different:

RingElem x(R1,1);
RingElem y(R2,2);
RefRingElem z(x);
x = y;
cout << "z=" << z << endl;

Recall that the ring to which z belongs cannot be changed, and it would require a significant redesign to produce a mechanism for informing z (and any other references) that it is now dangling.

What to do???