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.
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
the environment for the arithmetics, that is:
SparsePolyRing involved
DivMaskRule
PPMonoid for LPPForDiv
ring of coefficients (field or FrFldOfGCDDomain)
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)
constant GBEnv and the flags related with the algorithm:
GBCriteria is in GReductor
constant GBInfo and the "frozen computation":
Partial steps for the conversion of the current code:
GRingInfo as argument into GRingInfo
member functions (wip)
Good to know:
GRI.
Everything so far is just work in progress.
2010
GRingInfo into GBEnv.H,C