CoCoA » CoCoALib

The problem was originally communicated to JAA via email. The following is a failing example:

auto Q = CoCoA::RingQQ();
auto Qx = CoCoA::NewPolyRing(Q, CoCoA::symbols("x"));
auto x = CoCoA::indets(Qx)[0];
auto cf = x*x-2;
auto Qadjx = CoCoA::NewQuotientRing(Qx, CoCoA::ideal(cf));
auto Qy = CoCoA::NewPolyRing(Qadjx, CoCoA::symbols("y"));
auto y = CoCoA::indets(Qy)[0];
auto cg = y*y - 3;
auto Qadjy = CoCoA::NewQuotientRing(Qy, CoCoA::ideal(cg));
auto Qz = CoCoA::NewPolyRing(Qadjy, CoCoA::symbols("z"));
auto z = CoCoA::indets(Qz)[0];
auto ch = z*z*z*z-4;
std::cout << "factor(" << ch << ") = " << CoCoA::factor(ch) << std::endl;

The call to factor (in the last line) fails and throws an error about unsuitable indet name.

We first had this "friendly" pseudo constructor because the syntax for indet names was tedious.
Now we have SymbolRange, and NewPolyRing(RingQQ(), symbols("x,y,z")) which is even nicer.
(maybe we should even allow NewPolyRing(RingQQ(), "x,y,z")?)

So, after defending them for ages, I'm now in favour of removing the pseudo constructors taking just the number of indets.

I see two possible actions:
(A) remove completely the pseudo-ctor which accepts just the number of indets; the caller must then supply indet names in the call e.g. NewPolyRing(QQ, NewSymbols(nvars))
(B) keep the ctor, and make it use "anonymous" symbols instead of x[1], x[2], etc

An advantage of (A) is that it is clear at the point of the call that anon symbols will be used.
A disadvantage of (A) is that the call itself is longer (since it must call NewSymbols(nvars).
The advantage of (B) is that it is backward compatible (but how many times is NewPolyRing(QQ,nvars) called?)

Do you prefer (A) or (B) ? Opinions?

John Abbott wrote:

Do you prefer (A) or (B) ? Opinions?

I prefer A, as I had already explained.

Just to remember.
This should go into obsolescent.