SparsePolyRing

© 2005,2007 John Abbott
GNU Free Documentation License, Version 1.2



index page

User documentation for SparsePolyRing (and elements of a SparsePolyRing)

SparsePolyRing is an abstract class representing rings of polynomials; in particular, rings of sparse multivariate polynomials with a special view towards computing Groebner bases and other related operations. This means that the operations offered by a SparsePolyRing on its own values are strongly oriented towards those needed by Buchberger's algorithm.

Currently there are four functions to create a polynomial ring:

NewPolyRing(CoeffRing, NumIndets)
This creates a sparse polynomial ring with coefficients in CoeffRing and having NumIndets indeterminates. The PP ordering is StdDegRevLex. CoCoALib chooses automatically some names for the indeterminates (currently the names are x[0], x[1], ... , x[NumIndets-1]).

NewPolyRing(CoeffRing, IndetNames)
This creates a sparse polynomial ring with coefficients in CoeffRing and having indeterminates whose names are given in IndetNames (which is of type vector<symbol>). The PP ordering is StdDegRevLex.

NewPolyRing(CoeffRing, IndetNames, ord)
This creates a sparse polynomial ring with coefficients in CoeffRing and having indeterminates whose names are given in IndetNames (which is of type vector<symbol>). The PP ordering is given by ord.

NewPolyRing(CoeffRing, PPM)
This creates a sparse polynomial ring with coefficients in CoeffRing and with power products in PPM which is a power product monoid which specifies how many indeterminates, their names, and the ordering on them.

Examples

A polynomial is viewed abstractly as a formal sum of ordered terms; each term is a formal product of a non-zero coefficient (belonging to the coefficient ring), and a power product of indeterminates (belonging to the PPMonoid of the ring). The ordering is determined by the ordering on the power products: distinct terms in a polynomial must have distinct power products. The zero polynomial is conceptually the formal sum of no terms; all other polynomials have a leading term being the one with the largest power product in the given ordering.

Operations on a SparsePolyRing

We list here the operations available for an object of type SparsePolyRing; you should also consult the documentation in PolyRing.txt for operations on more general sorts of polynomial ring.

Let P be an object of type SparsePolyRing. Let R be an object of type ring.

Operations on Elements of a SparsePolyRing

In addition to the standard ring and PolyRing operations, elements of a SparsePolyRing may used in other functions. Let P denote a SparsePolyRing. Let f denote a non-const element of P. Let f1, f2 denote const elements of P. Let expv be a vector<long> of size equal to the number of indeterminates.

c is in CoeffRing(P), and x[i] are the indets of P.

-

!!Use these two functions with great care (c may be 0):

the corresponding member functions myPushFront/myPushBack will not check the validity of these assumpions: they should have a CoCoA_ASSERT to check in DEBUG mode.

Operations on SparsePolyIters

Let i1 and i2 be two SparsePolyIters running over the same polynomial.

Maintainer documentation for SparsePolyRing

The exact nature of a term in a polynomial is hidden from public view: it is not possible to get at any term in a polynomial by any publicly accessible function. This allows wider scope for trying different implementations of polynomials where the terms may be represented in some implicit manner. On the other hand, there are many cases where an algorithm needs to iterate over the terms in a polynomial; some of these algorithms are inside PolyRing (i.e. the abstract class offers a suitable interface), but many will have to be outside for reasons of modularity and maintainability. Hence the need to have iterators which run through the terms in a polynomial.

The implementations in SparsePolyRing.C are all very simple: they just conduct some sanity checks on the function arguments before passing them to the PolyRing member function which will actually do the work.

Bugs, Shortcomings and other ideas

Too many of the iterator functions are inline. Make them out of line, then use profiler to decide which should be inline.

PushFront and PushBack do not verify that the ordering criteria are satisfied.

Verify the true need for myContent, myRemoveBigContent, myMulByCoeff, myDivByCoeff, myMul (by pp). If the coeff ring has zero divisors then myMulByCoeff could change the structure of the poly!

Verify the need for these member functions: myIsZeroAddLCs, myMoveLM, myDeleteLM, myDivLM, myCmpLPP, myAppendClear, myAddClear, myAddMul, myReductionStep, myReductionStepGCD, myDeriv.

Should there be a RingHom accepting IndetImage (in case of univariate polys)?