Feature #606

Evaluate in ring operator (was called :: in CoCoA-4)

Added by Anna Maria Bigatti over 3 years ago. Updated over 1 year ago.

CoCoA-4 function to be added
Target version:
Start date:
19 Mar 2014
Due date:
% Done:


Estimated time:
4.00 h
Spent time:


CoCoA-4 has the :: operator which evaluated expressions in a given ring:


It would be nice to have something similar in CoCoA-5; this would make it easier to specify poly ring homomorphisms, perhaps like this

P1 ::= QQ[x,y];
P2 ::= QQ[a,b];
PolyAlgHom(P1, P2, P2::[a^2,b^3]);

Currently you must Use P2 to create the vector of indet images, and then pass that to PolyAlgHom. This is relevant only at top level, I think.
or ReadExpr:
PolyAlgHom(P1, P2, [ReadExpr(P2,"a^2"), ReadExpr(P2,"b^3")])

Related issues

Related to CoCoA-5 - Feature #484: Evaluate in other ring (was called :: in CoCoA-4)Closed2014-03-19

Related to CoCoA-5 - Bug #878: RingElem applied to a symbol (repr as a string)Closed2016-05-09


#1 Updated by John Abbott almost 3 years ago

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

#2 Updated by John Abbott about 2 years ago

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

It might not be too painful if ReadExpr could read lists as well. The example in the issue description could then become:

PolyAlgHom(P1, P2, ReadExpr(P2,"[a^2,b^3]"));

Maybe there could be a fn called ReadExprList if we do not like extending ReadExpr to return different types of result.

I admit that it does "feel funny/awkward" having to put the value inside a string which is parsed only at run-time... it could be nice to have read-time parsing (but that would presumably need a new syntax).

Anyway, delaying this issue to some future version of CoCoA-5.

#3 Updated by John Abbott almost 2 years ago

  • Related to Bug #878: RingElem applied to a symbol (repr as a string) added

#4 Updated by John Abbott over 1 year ago

The suggestion of another function (perhaps called ReadExprList) still seems good to me.

Hmmm, but then again a list of lists would still be problematic :-/
In C++ the fn needs to have a well-defined return type, so we really do need different fns names for different return types (assuming the args continue to be a ring and a string).

Also available in: Atom PDF