CoCoA » CoCoALib

There should probably be a "graded" mode, and then the possibility to know whether the partial/truncated basis is complete up to some degree.
If we ever want to implement Groebner trace then it would be helpful to be able to extract the trace from a GBMill -- this probably makes sense only when the computation is complete?

I would also like to be able to perform a GB computation in chunks determined by a time-out. It may suffice to have a ProceedForTime function; or is there a better interface?

A possible advantage of using "funny" indet names is that it is then clear that the value does not belong to the original poly ring.
A disadvantage is that debugging could be a real headache...

One the phone I had mentioned the possibility of "exporting" an internal polynomial to the original ring. This would automatically use the expected indet names, but the leading PP may not be the first one printed (if the internal ring has a different term order).
An "export" function would be useful/needed when producing a truncated GB. Also I have an application (find extra gens prior to computing the homogenization) where I want to find quickly some "small" polys in the ideal e.g. compute a "partial" GB with a time limit, then check to see if there are any small polys. Again this would require exporting the poly... it is no importance that the LPP may not be the first.

As a guideline: in CoCoA-4 there was the Groebner Framework:

instead of using one of the normal Groebner
basis-type commands (listed in the previous section), start the
computation with one of the commands,
  * GB.Start_GBasis -- start interactive Groebner basis computation
  * GB.Start_MinGens -- start interactive minimal generator calculation
  * GB.Start_Res -- start interactive resolution computation
  * GB.Start_Syz -- start interactive syzygy computation

After starting the computation, the following commands are available:
  * GB.Complete -- Complete an interactive Groebner-type calculation
  * GB.GetBettiMatrix -- returns the Betti matrix computed so far
  * GB.GetNthSyz -- returns the part of the Nth syzygy module computed so far
  * GB.GetNthSyzShifts -- shifts of the Nth syzygy module computed so far
  * GB.GetRes -- returns the resolution computed so far
  * GB.GetResLen -- returns the length of the resolution computed so far
  * GB.ResReport -- status of an interactive resolution calculation
  * GB.Stats -- status of an interactive Groebner-type calculation
  * GB.Step, GB.Steps -- take steps in an interactive Groebner-type calculation
  * ReducedGBasis -- compute a reduced Groebner basis

//==========================  EXAMPLE  ==========================\\
  Use R ::= QQ[t,x,y,z];
  I := Ideal(t^3-x, t^4-y, t^5-z);
  $gb.Start_GBasis(I);  -- start the interactive framework
  I.GBasis;  -- the Groebner basis is initially empty
Null
-------------------------------
  $gb.Steps(I,1); -- a single step of the computation
  I.GBasis;
[t^3 - x]
-------------------------------
  $gb.Steps(I,4); -- 4 more steps
  I.GBasis;
[t^3 - x, -tx + y, t^2y - x^2]
-------------------------------
  $gb.Complete(I); -- complete the computation
  I.GBasis;
[t^3 - x, -tx + y, -ty + z, -y^2 + xz, -x^2 + tz, t^2z - xy]
-------------------------------
  ReducedGBasis(I);
[t^3 - x, tx - y, ty - z, y^2 - xz, x^2 - tz, t^2z - xy]
-------------------------------
\\==========================  o=o=o=o  ===========================//

John Abbott wrote:

A possible advantage of using "funny" indet names is that it is then clear that the value does not belong to the original poly ring.
A disadvantage is that debugging could be a real headache...

That's why I'm undecided. I'll follow my approach (when/after finished) I'll try them both and see how I feel about using them. (this should be a small change in the code)

One the phone I had mentioned the possibility of "exporting" an internal polynomial to the original ring. This would automatically use the expected indet names, but the leading PP may not be the first one printed (if the internal ring has a different term order).

I think we should output the internal representation, and also offer the homomorphism to bring it in the input ring.
So I can write phi(LPP), or LPP), depending on what I need to look at.

An "export" function would be useful/needed when producing a truncated GB. Also I have an application (find extra gens prior to computing the homogenization) where I want to find quickly some "small" polys in the ideal e.g. compute a "partial" GB with a time limit, then check to see if there are any small polys. Again this would require exporting the poly... it is no importance that the LPP may not be the first.

Ideally this framework should have no overhead compared to the usual GBasis call, so that we can implement all the GB variations using it (truncation, MinGens, ...)

John Abbott wrote:

A possible advantage of using "funny" indet names is that it is then clear that the value does not belong to the original poly ring.
A disadvantage is that debugging could be a real headache...

That's why I'm undecided. I'll follow my approach (when/after finished) I'll try them both and see how I feel about using them. (this should be a small change in the code)

One the phone I had mentioned the possibility of "exporting" an internal polynomial to the original ring. This would automatically use the expected indet names, but the leading PP may not be the first one printed (if the internal ring has a different term order).

I think we should output the internal representation, and also offer the homomorphism to bring it in the input ring.
So I can write phi(LPP), or LPP), depending on what I need to look at.

An "export" function would be useful/needed when producing a truncated GB. Also I have an application (find extra gens prior to computing the homogenization) where I want to find quickly some "small" polys in the ideal e.g. compute a "partial" GB with a time limit, then check to see if there are any small polys. Again this would require exporting the poly... it is no importance that the LPP may not be the first.

Ideally this framework should have no overhead compared to the usual GBasis call, so that we can implement all the GB variations using it (truncation, MinGens, ...)

1. prepare an ideal/ideal-like submodule in a specific ring/FreeModule (with ordering)
2. compute the GBasis of this ideal/submodule
3. extract the information from it and convert it into the desired result.

Thus the GroebnerMill should have all the information (homomorphisms, actual operations, meaning of indeterminates, ...) to extract and convert the data from within the GBasis computation in the core.