# GBEnv

© 2010 Anna Bigatti
GNU Free Documentation License, Version 1.2

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

CoCoALib Documentation Index

## 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 `GPoly`s 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`