CoCoA » CoCoA-5

Same problem with radical(J).

Bad news: the problem occurs somewhere inside Max's code :-(

The problem is that EmbedPolyList tries to create a GPoly starting from a zero polynomial, but the ctor wants to compute the LPP of the starting poly.

I tried hacking EmbedPolyList (lines 1489-1501 in TmpGReductor.C) so that the main loop skips zero polys; this caused another problem in myPrepareGBasis because the list myPairs is empty, but an assert says it should be non-empty.

What to do?

radical seems happy so long as there is at least one non-zero generator.
However, radical(ideal(one(R))) gives a very strange error message!

intersect appears to exhibit the problem if either ideal has a zero generator;
I tried ideal(x,0) and ideal(y,0) where 0 represents zero(R)

Anna says she knows a fix for intersect.

Strictly, the issue belongs to CoCoALib.

Should there be a separate issue about putting some proper "extreme case" tests for all ideal operations in the standard test suite(s)? Probably best in the CoCoALib tests!

The tests should cover char 0 and char p. Perhaps some non-trivial coeffs rings too?

The mem fn myColon is called by colon (see source ideal.C:280) which makes a copy of I and then "plays" with the gens of that copy -- this does not change the original arg (which is const).

What I tried to suggest yesterday, is that an ideal could contain two lists of generators: one is the list the user supplied, the other is a "cleaned list" e.g. without zero values, maybe without duplicates, maybe made monic, perhaps put into a good order, etc. I can see one problem: which list should be used when printing the ideal? Presumably the original user-supplied list should be returned by the mem fn myGens (or whatever it is called). Mmmm, it could be confusing to have two lists... Unless the "cleaned list" is used only when calling ideal operations...???

John Abbott wrote:

The mem fn myColon is called by colon (see source ideal.C:280) which makes a copy of I and then "plays" with the gens of that copy -- this does not change the original arg (which is const).

I expect we could do the same for intersect

What I tried to suggest yesterday, is that an ideal could contain two lists of generators: one is the list the user supplied, the other is a "cleaned list" e.g. without zero values, maybe without duplicates, maybe made monic, perhaps put into a good order, etc. I can see one problem: which list should be used when printing the ideal? Presumably the original user-supplied list should be returned by the mem fn myGens (or whatever it is called). Mmmm, it could be confusing to have two lists... Unless the "cleaned list" is used only when calling ideal operations...???

I think the cleaned list could be hidden to the user, a bit like the gbasis.
For monomial ideals it would be handy to have the list of PPs in a similar fashion.
A template member field? (boggle)

We must remember to add CoCoALib tests for all these "trivial cases" -- they should be in CoCoALib rather than CoCoA-5, I believe.

Do the myIntersect functions have assertions that their args are valid?

ehm.... most of them yes ;-) except SparsePolyRing ideals (I think).

Looking at all of them I'm getting convinced we should make a "myAssignZero" which knows, for any implementation, all the fields to be cleared.

added test in cocoalib. closing.