CoCoA » CoCoALib

• what is the answer? List of polys which are actually indets? List of indices?
• should "indets" in the coeff ring be considered?
• to what types can it be applied? RINGELEM, LIST, IDEAL??, MATRIX

What should it be called? indets is already defined for rings; we could extend that, or else use a new name.

John Abbott wrote:

If the answer is yes then we must decide some things:

• what is the answer? List of polys which are actually indets? List of indices?

in CoCoALib it should be the list of indices, in CoCoA-5 I'm not sure...

• should "indets" in the coeff ring be considered?

no

• to what types can it be applied? RINGELEM, LIST, IDEAL??, MATRIX

RINGELEM yes
IDEAL no (generator dependant)
LIST inclined for no (elements might be in different rings!)
MATRIX maybe

What should it be called? indets is already defined for rings; we could extend that, or else use a new name.

indets would be ambiguous, I believe. Said that, I cannot think of another good name ;-)

A possible name: IndetsIn

I would like to have IndetsIn also for a list (which is assumed to be "homogeneous", i.e. all elements in the same poly ring o/w error). I used it in some CoCoA-5 code for checking whether a set of conditions defines an arithmetic group (these conditions would then become generators of an ideal).

• InvolvesOnlyTheseIndets which returns a bool -- could be much faster than checking IndetsIn for being a subset
• PolyInIndetPower which returns a list of PPs such that the arg is a polynomial in these PPs (e.g. given x^10+x^5+2 the result would be x^5)

The second fn is potentially quite complicated, but could be useful for mapping some multivariate polynomials down to simpler ones. Hmmm, technically a homogeneous bivariate polynomial is "equivalent" to a univariate polynomial, but it would not fit this scheme... :-/

NOTE we can consider InvolvesOnlyTheseIndets if some genuine applications for it arise.

NOTE2 I am not sure what semantics the fn PolyInIndetPower should have; it could certainly be useful in GCD and factorization...

I have impl'ed a first version (simple rather than efficient).
Not yet checked in; I want to do some testing first.

• A a list of integer indices (presumably of type vector<long>)
• B a vector "bools" with k-th posn being set to "true" if k-th indet is present

A possible advantage of B is that it would allow checking to finish early if all entries are "true" (e.g. when checking a list of polynomials, checking could end part way through a poly even if that poly does not contain all indets). Not sure how genuinely useful this could be.

We could even offer both interfaces (but that seems excessive for a seemingly unimportant function).

In B the return type vector<bool> is probably a poor choice because I suspect that setting individual bits is likely to be costly; vector<int> should be faster -- I'll check! ANSWER [in IndetsIn in SparsePolyRing.C:965] there's very little difference (hardly measurable), so vector<bool> is a better choice because it more clearly expresses the purpose.

also related to #91

An advantage of vector<bool> is that it avoids the problem/incompatibility of indices in C++ starting from 0 (both for vectors and indets) whereas in CoCoA-5 they start from 1.

This is definitely needed: There are awkward work-arounds in radical.cpkg5 and in BringIn.cpkg5.

Checked in IndetsIn(vector<RingElem>)