Project

General

Profile

Design #637

Undesirable consequence of automatic mapping of RingElems?

Added by John Abbott over 9 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
John Abbott
Category:
enhancing/improving
Target version:
CoCoA-5.4.0
Start date:
23 Oct 2014
Due date:
% Done:

100%

Estimated time:
1.81 h
Spent time:
1.80 h

Description

Suppose we allow automatic mapping of ringelems into superrings.
Consider the following scenario:

QQa ::= QQ[a];
use P ::= QQa[x];
A := RingElem(QQa, "a"); // a viewed as elem of QQa
B := (x+A)-x;
deg(A); --> 1
deg(B); --> 0
A = B;  --> true|false|error?

The variables A and B contain "equivalent" values: for instance (x+A) = (x+B) surely gives true. What should the comparison A = B produce?

Related issues

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

Related to CoCoA-5 - Design #636: Distinguish indets from symbols in coeffring in Use commandRejected2014-10-23

Related to CoCoA-5 - Design #635: Automatic mapping of RingElem (in operation with a compound value)Closed2014-10-22

Related to CoCoALib - Feature #223: Automatic mapping of RingElemsClosed2012-08-08

Related to CoCoA-5 - Feature #1461: Automatic mapping for multiplication?Closed2020-06-10

Related to CoCoALib - Design #1515: Indets in coeffring are ringelems in coeffring?Rejected2020-10-22

Related to CoCoALib - Feature #645: Automatic mapping of RingElem: user selectable at run-time (GlobalManager?)Rejected2014-11-04

History

#1 Updated by John Abbott over 9 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

I think the values of deg(A) and deg(B) are well defined.

If we have not(deg(A) = deg(B)) then it would be quite a (nasty?) surprise to have simultaneously A=B.
Since we have (x+A) = (x+B), it would be a nasty surprise to have simultaneously not(A=B).

The only option left is for the comparison A=B to produce an error (?mixed rings?).

Automatic mapping means that A-B evaluates to 0. Do we really want two values whose difference is zero to be incomparable???

Help?!?

#2 Updated by John Abbott over 9 years ago

Here is a short session valid with the current version of CoCoA-5

Fpx ::= ZZ/(7)[x];
FrF := NewFractionField(Fpx);
A := 2/3;
B := RingElem(FrF,A);
A = B; --> true
num(A);--> 2
num(B);--> 3

In other words we have two values which test as equal but which have different numerators. No one has complained loudly about this. Perhaps I should not be so worried about two equal values having different degrees?

What do you think?

#3 Updated by John Abbott over 9 years ago

While talking to Anna the following idea came up. Non-simple elements of coefficient rings are printed inside brackets, except if the element is the coefficient of 1 in a polynomial ring. We could change the rules for using brackets so that elements of subrings are always printed in brackets (incl. elements of finite fields?). Thus in the example in the preceding comment num(B) would print out as (3) rather than a plain 3; the idea is that the brackets warn the user that the printed value is not exactly as it seems.

Similarly in the example given in the description the two printed values would be different: one without brackets, namely just a, and the other with, namely (a).

These brackets could be useful for informing the reader that the value is not "plain", but it might also "uglify" printing in general (when perhaps distinguishing the cases in not so important). In any case the RingOf function can always be used to find out where the value resides.

Comments? Criticisms?

#4 Updated by John Abbott almost 9 years ago

  • Target version changed from CoCoA-5.1.2 summer 2015 to CoCoA-5.1.3/4 Jan 2016

#5 Updated by Anna Maria Bigatti about 8 years ago

  • Target version changed from CoCoA-5.1.3/4 Jan 2016 to CoCoA-5.?.?

#6 Updated by Anna Maria Bigatti almost 4 years ago

  • Related to Feature #1461: Automatic mapping for multiplication? added

#7 Updated by John Abbott over 3 years ago

  • Target version changed from CoCoA-5.?.? to CoCoA-5.4.0
  • % Done changed from 10 to 20

I have just tried the example in the description. The equality test gives ERR::MixedRings, which I think is probably "correct".

#8 Updated by John Abbott over 3 years ago

  • % Done changed from 20 to 30

I now suggest that we make equality-test throw an error (MixedRings) if the args are elements of two different rings.
If it later turns out to be awkward, we can revise the design -- not strictly backward compatible (but "removing an error case" could be viewed as progress).

Strictly this issue should be under CoCoALib...

#9 Updated by John Abbott over 3 years ago

  • Related to Design #1515: Indets in coeffring are ringelems in coeffring? added

#10 Updated by John Abbott over 3 years ago

  • Status changed from In Progress to Closed
  • Assignee set to John Abbott
  • % Done changed from 30 to 100
  • Estimated time set to 1.81 h

Conclusion: no automatic mapping of ringelems in equality tests

A user working in several rings at once has to some responsibility for handling things correctly; it seems too hard to "read the user's mind".
The safe option seems to be to throw an exception... hopefully experience will confirm this decision.

PS Anna agreed while discussing this.

#11 Updated by Anna Maria Bigatti 2 months ago

  • Related to Feature #645: Automatic mapping of RingElem: user selectable at run-time (GlobalManager?) added

Also available in: Atom PDF