CoCoA » CoCoALib

Mario will try to put all his source code in his own namespace (perhaps called involutive), and will put all his files into a subdirectory of src/AlgebraicCore/.

In the following I try to explain how I integrated the JBMill/PBMill into SparsePolyRing::IdealImpl:

UIBC¶

First of all I implemented a Involutive::UniversalInvolutiveBasisContainer (UIBC). It is designed to use it with SmartPtrIRC. The UIBC should act as a wrapper between JBMill/PBMill and the IdealImpl. It is initialized with a arbitrary generating set and it will only calculate a Janet basis it is really necessary. Once a Janet basis or an invariant is computed we store it in the UIBC and every additional call only take the already computed value.

Integrate UIBC to SparsePolyRing::IdealImpl¶

I add the following data member to SparsePolyRing::IdealImpl

SmartPtrIRC<Involutive::UniversalInvolutiveBasisContainer> myInvBasisContainerPtr;

  const std::vector<RingElem>& SparsePolyRingBase::IdealImpl::myJanetBasis() const
  {
    return myInvBasisContainerPtr->myJanetBasis();
  }

  bool SparsePolyRingBase::IdealImpl::InvIamDeltaRegular() const
  {
    return myInvBasisContainerPtr->IamDeltaRegular();
  }

  const std::vector<RingElem>& Involutive::JanetBasis(const ideal& I)
  {
    if (!IsSparsePolyRing(RingOf(I)))
      CoCoA_ERROR(ERR::NotSparsePolyRing, "JanetBasis(I)");
    const SparsePolyRingBase::IdealImpl* const ptrI =
      SparsePolyRingBase::IdealImpl::ourGetPtr(I);
    return ptrI->myJanetBasis();
  }

  bool Involutive::IsDeltaRegular(const ideal& I)
  {
    if (!IsSparsePolyRing(RingOf(I)))
      CoCoA_ERROR(ERR::NotSparsePolyRing, "JanetBasis(I)");
    const SparsePolyRingBase::IdealImpl* const ptrI =
      SparsePolyRingBase::IdealImpl::ourGetPtr(I);
    return ptrI->InvIamDeltaRegular();
  }

To define these methods I have to declare Involutive::JanetBasis(const ideal& I) and Involutive::IsDeltaRegular(const ideal& I) as friend in SparsePolyRingBase.

A few thoughts about this solution¶

In principal it works, but there are some points which I do not like:

• I have to define many new friends in SparsePolyRingBase. I am not sure if this is a clean solution.
• The methods Inv... are only wrappers for the corresponding methods in the UIBC. Maybe it is a better solution to make the UIBC accessible for the global methods like JanetBasis and IsDeltaRegular. Then we could get rid of these methods.

Here is a brief "one-way discussion" about some function interfaces: I shall consider just IsMonomial, but it is a model for several other functions.

An unsophisticated user will want to simply call IsMonomial(I) and get the answer "as quickly as possible"; so it is CoCoALib's responsibility to pick the best way.

An ideal might have a bool3 flag to represent knowledge about whether the ideal is monomial or not; if the flag is set "definitely" then the answer is immediate. But remember that such flags require careful handling to work properly in a multi-threaded context!

Assuming we cannot get an immediate answer from such a flag. If I already has a G-basis or a J-basis then we can use the basis to get the answer quickly. If both bases are available, is one a better choice than the other? My guess is that a G-basis typically has fewer elements, so that would be a better choice when the ideal actually (or probably) is monomial. I have no intuition about the case when the ideal is (probably) not monomial.

If neither basis exists, at least one must be computed. Which? (and why?)

A more advanced user may want to force the use of one basis or another for the computation; how can this be done neatly?

A simple interface is: a function which forces computation of a GBasis (without copying the result), and a function which forces computation of a JBasis (without copying the result).

Mario points out that there may be extra parameters specifying details of the algm to use for computing the JBasis; probably something similar should apply also to computation of GBasis (e.g. disabling/enabling various criteria).

Addendum JAA thinks it is probably worth making this simple interface (perhaps even without the extra algm parameters initially), then later we can consider making it more sophisticated based on users' demands.