GBEnv

• User documentation
• Maintainer documentation
  • GBEnv will know
  • GBInfo will know
  • GBMill/BuchbergerMill (?) will know -- was GReductor
• Bugs, shortcomings and other ideas
• Main changes

User documentation

This class contains some information needed for the computation of a GBasis (with Buchberger's algorithm)

At the moment the file contains instead the class GRingInfo which was defined in TmpGPoly.H

One idea to unify the class of ideals in SparsePolyRing is to make an abstract GBMill as a base for the the operation on ideals (toric, squarefree, ideals of points,..) For standard ideals the key for the (GB)operations is computing with Buchberger algorithm, therefore the BuchbergerMill should inherit from GBMill.

Maintainer documentation

As one class should do one thing GRingInfo and GReductor should reorganized and split into GBEnv, GBInfo, and GBMill.

Mill: A building equipped with machinery for processing raw materials into finished products

GBEnv will know

the environment for the arithmetics, that is:

• the SparsePolyRing involved
• the DivMaskRule
• the PPMonoid for LPPForDiv
• the ring of coefficients (field or FrFldOfGCDDomain)
• if it represents a module computation
• the "module/ring" embeddings (or GBHom ???)
• ---> inheritance for the module case?

Notes

Embeddings/deembeddings are now in TmpGReductor: they embed polynomials and ModuleElems into GPolys therefore cannot directly be GBEnv member functions (i.e. GBEnv would need GPoly forward declaration or .H inclusion)

Should embeddings/deembeddings be a class on their own? or just functions in a file on their own? or where?

The main difference between ring and module computations is in considering the component in IsDivisibleFast. How to balance efficiency and inheritance? (The other difference is in making pairs of polynomials with the same component)

GBInfo will know

constant GBEnv and the flags related with the algorithm:

• if the input was homogeneous (for interreduction?)
• alg homog/aff/sat/hdriven...
• the kind of sugar function to use
• active criteria (Weyl/module). Now GBCriteria is in GReductor
• ...

GBMill/BuchbergerMill (?) will know -- was GReductor

constant GBInfo and the "frozen computation":

• the input polynomials
• list of pairs
• list of reducers
• list for output
• reducing SPolynomial (or atomic ???)
• stats
• ...

Some general notes

Partial steps for the conversion of the current code:

1. use member function in ctor for common assignments (done)
2. transform functions with GRingInfo as argument into GRingInfo member functions (wip)

Good to know:

1. reduce.C uses only "env" info from GRI.
2. GRingInfo has many fields, completely unused in the basic case (ie GB for polys). Some are set with a default value which is different for some "concrete classes" (eg modules, operation specific)
3. SPoly creates a GPoly with "env" info, only sugar needs "mill"; in fact the constructor for GPoly needs "mill" only for sugar: we can make an "undefined" sugar to be set later on.

Bugs, shortcomings and other ideas

Everything so far is just work in progress.

Main changes

2010

• moved definition of class GRingInfo into GBEnv.H,C