CoCoA » CoCoALib

I am not yet sure of the details, but I am hoping that it can be used as in this example:

  ring P = NewPolyRing(...);
  RingElem f(P, "x^2-y");
  homogenizer H(P); // optional second arg saying where the homog indet should be (first/last)
  RingElem f_hom = H(f);
  ideal I = ideal([...]);
  ideal I_hom = H(I);

The ctor for homogenizer will internally create the extended poly ring, P_hom, and
also the mapping of indeterminates of P into P_hom. It will also be possible to
use the homogenizer to dehomogenize (not sure what syntax to use).

Following KISS, it is probably best to try the simple interface first.
If it works well, and we like it, then we can consider offering more
options: e.g. letting the caller specify the extended poly ring, and
how the indeterminates should map.

This way all sanity checking can be done in the ctor for homogenizer,
and all later calls will not need to check much.

The ctor for homogenizer will create the extended polynomial ring.
What properties should this extended ring have?
Same coeff ring, of course.
Term ordering? Presumably compatible with that of the starting ring,
and such that the homogenizing indets have weights like the columns in
an identity matrix. But what happens below the weights in the order
matrix for the big poly ring? Maybe it depends on the intended use?

This is for JOHN Knuckle down and do it!

The interface in OSCAR lets the caller choose where the "new" indeterminates appear in the list of indets of the bigger ring.
In most cases the caller chooses "before all the others" or "after all the others". What do we want to do?

• homog ring (usu. with indets x[0], x[1], ..., x[n], by default std graded (but other gradings allowed; all indets have non-zero wdeg)
• n+1 poly rings generated by the n+1 subsets of n indets
• n+1 dehomogenizers, and n+1 homogenizers

If the grading is not standard then some homogenizers may be partial maps (but each homogenizer is a full map on the image its corresponding dehomogenizer). The code is simple (if a bit tedious). Also need to invent a neat UI.

The basic way of creating a homogenizer/dehomogenizer pair does not adapt directly to this use-case.

• Qn each ring has its own mem mgr: so this means that each ring will create at least 1 "loaf" -- how much memory is this?
• Ans the first loaf has size 1024 bytes (see near line 92 in src/AlgebraicCore/MemPool.C)
• Qn are rings automatically deleted when no longer needed?
• Ans Yes unless the dodgy THREADSAFE compilation option was activated.

Also we do not expect that the function will be used for high-dimensional projective space (e.g. at most 5 indets)