CoCoA » CoCoA-5

The interfaces to ContentWRT and CoefficientsWRT are awful -- they seemed reasonable when I designed them, but then I tried to use them...

I propose adding the following interfaces for the case of a single indet:

ContentWRT(f,x);
CoefficientsWRT(f,x);

where f represents a polynomial, and x represents a ringelem which is an indet (and not the index of the indet!)

If we accept the above "simple" interface then we should also consider the following extension (which I think should probably replace the existing interface):

Content(f, [x,y]);
Coefficients(f, [x,y]);

where f is a poly, and x and y are ringelems whose values are indets.

If we accept any of the proposals above then we should consider analogous changes to the interfaces to the homonymous functions in CoCoALib.

I think we should keep both interfaces: Co**WRT and Co**WRT
The first is very convenient, but the second one is more direct.
Consider this example

Use S ::= QQ[a,b,c];
F := a*b + b*c;
Use R ::= QQ[x,y,z];
/*do something with*/  ContentWRT(F, [1]);

it would inefficient to write

ContentWRT(F, Indet(S,1));

when the first thing done by the function is to check if Indet(S,1) is an indeterminate...

Anna Maria Bigatti wrote:

it would inefficient to write...

Yes, but I believe the run-time inefficiency would be negligible.

Perhaps you are right that we should offer both interfaces? Undoubtedly the interface accepting a RingElem whose value is an indet is the most natural and convenient for interactive use. In contrast the "indet index" interface is much closer to the interface available in CoCoALib (apart from the difference of 1 in index values); then again the difference in index values might be a good reason not to offer the "indet index" interface in C5 -- otherwise "mechanical" translating of C5 into CoCoALib code runs the risk of producing code that looks right but has the wrong behaviour.

Here are some arguments in favour of the interface which wants a list of RINGELEM to specify which indets:

• JAA believes it is easier to use and more natural than using indices (and probably also less error prone -- wysiwyg)
• it is resilient under changes to the order of indets in the ring specification (or if new indets are introduced)
• using RINGELEMs allows run-time checking that the indets specified do indeed belong to the correct ring (this cannot be done with the indices)

While recognizing the validity of Anna's example favouring the use of indices, JAA think it is better to offer just a single type of interface (at least initially). Remember it is easier/safer to extend an interface than to restrict it.

At the moment it is not clear to JAA what the CoCoALib interface should be if we adopt the RINGELEM interface in CoCoA-5. JAA thinks the naturalness and ease-of-use point becomes much weaker in CoCoALib -- the other points remain valid.

John Abbott wrote:

At the moment it is not clear to JAA what the CoCoALib interface should be if we adopt the RINGELEM interface in CoCoA-5. JAA thinks the naturalness and ease-of-use point becomes much weaker in CoCoALib -- the other points remain valid.

OK. I'll change the cocoa-5 interface. I'm inclined to leave cocoalib as it is (i.e. vector of indices)

In CoCoALib CoefficientsWRT accepts both a RingElem and a list of indets as 2nd arg, and produces the same type of result (namely vector<CoeffPP>).

We could consider other names, e.g. CoeffListWRT and CoeffVecWRT?

I do have a mild preference for slightly different names (corresponding to the differing return types).