Project

General

Profile

Design #635

Automatic mapping of RingElem (in operation with a compound value)

Added by John Abbott over 9 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
High
Assignee:
John Abbott
Category:
enhancing/improving
Target version:
CoCoA-5.4.2
Start date:
22 Oct 2014
Due date:
% Done:

100%

Estimated time:
Spent time:
2.55 h

Description

If we decide to allow automatic mapping of RingElem values, Anna suggests that only simple/single values can be automatically mapped.

Thus in a product RingElem*Matrix only the RingElem may be mapped; similarly for operations between RingElem and lists|ideals.

To solve Robbiano's problem we should allow mapping down of a RingElem into a subring (if the value lies in the subring).

Discuss!

Related issues

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

Related to CoCoA-5 - Design #634: Symbol in the coeff ringRejected2014-10-22

Related to CoCoALib - Feature #113: Introduce PartialHomIn Progress2012-03-23

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

Related to CoCoA-5 - Design #637: Undesirable consequence of automatic mapping of RingElems?Closed2014-10-23

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

Robbiano's scenario was the following... a bit simplified:

QQab ::= QQ[a,b];
K := NewFractionField(QQab);
Use P ::= K[x,y];
M := mat(K, [[1,2],[3,4]]);
a*M;

The result should be a matrix over K; this requires "mapping down" the value of a into the subring K.

#2 Updated by John Abbott over 9 years ago

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

I note that this proposal would still produce an error if one tries to compute:

x*M;

because x cannot be mapped down into K (and if instead a result were produced, it would have to be a matrix over P).

Is this acceptable? Do we want this?

#3 Updated by Anna Maria Bigatti over 9 years ago

The description says it all, but I prefer phrase it also like this:

b * M;  -- b RingElem;  M matrix

b*M should be a matrix in the same ring as M.

Therefore this would not solve situations like

x * M;  -- x in QQ[x];  M over QQ

because the resulting matrix is not over QQ

This implementation can be done "easily" (so to speak...) but do we want to allow some cases and not others? allow RingElem * matrix, and matrix * RingElem, but not others?

The main problem is that, if we cannot find a general (mathematically robust) definition, we risk to have many exceptions, and to be more confusing than helpful.

#4 Updated by John Abbott over 9 years ago

At the moment the idea of automatically "mapping down" ring elements makes me feel uneasy (perhaps solely because I haven't given the matter much consideration up to now).

We must consider all cases of mapping down e.g. from R/I to R.

#5 Updated by John Abbott about 9 years ago

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

#6 Updated by Anna Maria Bigatti over 8 years ago

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

#7 Updated by Anna Maria Bigatti about 4 years ago

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

#8 Updated by John Abbott about 4 years ago

  • Target version changed from CoCoA-5.?.? to CoCoA-5.4.0

The example in comment 1 works with my current "internal" versions of CoCoA5.

#9 Updated by John Abbott over 3 years ago

  • % Done changed from 10 to 20

Clarification: the example in comment 1 does indeed run, but the resulting matrix is over P not K.
To obtain a matrix over K, one would have to map the scalar into K (e.g. by using LC(a)).

I am tempted to suggest closing this issue since the current impl "works".

#10 Updated by John Abbott over 3 years ago

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

#11 Updated by John Abbott over 3 years ago

  • % Done changed from 20 to 30

I must change the impl so that only the ringelem gets mapped. To map the matrix one must make an explicit call.

One reason for being uneasy about mapping the matrix is that it may be quite costly (if the matrix has many entries).

#12 Updated by John Abbott over 3 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 30 to 70

I have changed the impl so that there is no auto promotion for matrices.
The example in comment 1 now gives

ERROR: MixedRings: no auto promotion for matrices

Perhaps the error could be phrased better?

#13 Updated by Anna Maria Bigatti over 2 years ago

  • Target version changed from CoCoA-5.4.0 to CoCoA-5.4.2

#14 Updated by John Abbott over 1 year ago

  • Status changed from Resolved to Feedback
  • Assignee set to John Abbott
  • % Done changed from 70 to 90

I have changed the err mesg to be more comprehensible: "automatic" instead of "auto".

I think we can close this issue, right?

#15 Updated by Anna Maria Bigatti over 1 year ago

John Abbott wrote:

I have changed the err mesg to be more comprehensible: "automatic" instead of "auto".

what about

--> ERROR: MixedRings: no automatic promotion mapping for matrices

?

I think we can close this issue, right?

then yes

#16 Updated by Anna Maria Bigatti over 1 year ago

I added the manual search key "promotion mapping" to CanonicalHom and to matrix

#17 Updated by Anna Maria Bigatti over 1 year ago

  • Status changed from Feedback to Closed
  • % Done changed from 90 to 100

Added ".. promotion mapping .." (3 lines) and checked in.
Closing.

#18 Updated by Anna Maria Bigatti 5 months ago

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

Also available in: Atom PDF