If you are not a CoCoA library developer then most likely you should not be considering using this class -- use a polynomial ring instead. That way you will gain ease of use and safety with only a small performance penalty.
This class should be seen and used only by CoCoA library implementors; normal users should use the polynomial rings (which internally may well use DMPIs to represent their elements).
The class DistrMPolyInlPP implements multivariate polynomials represented as ordered linked lists of summands, each summand is made up of a coefficient (RingBase::RawValue) and a power product represented as an order vector.
The implementation is oriented towards speed rather than safety or ease of use. To this end argument sanity checks (and other types too) should normally use CoCoA_ASSERT rather than CoCoAError.
NO DOCUMENTATION YET WRITTEN.
This code is very ugly, and I am far from happy with it. I hope it will eventually become much cleaner while maintaining the speed.
The biggest bug is the definition of the struct summand which is NOT PORTABLE since C++ compilers do not guarantee to respect the order of fields in a structure. I do not yet know how best to avoid this without incurring a run-time penalty.
This code is apparently stable but surprisingly ugly and awkward to use. I continue to hope that the same speed can be achieved with cleaner code. As an example of how bad the code is just take a look at the function deriv (which computes derivatives) -- it is far too long and incomprehensible. There must be better way!
The classes DistrMPolyInlPP, PPMonoid and PPOrdering are more closely tied together than I would really like.
Iterators are giving me headaches -- we need them, but they seem to expose implementation details.