CoCoA » CoCoALib

What exactly should NewMatCompleteOrd do?
What does its expect as input? And what does it give as output? When does it give error?

From its name I would expect it to produce a term ordering "compatible" with the input matrix. Possibly the first rows of the resulting matrix must be equal to the input matrix.

What should NewMatCompleteOrd(ZeroMat(...)) do?
This might give error since it is not possible to produce a full-rank square matrix having first row full of zeroes -- if we adopt the semantics that the first rows must match. Currently this produces a deg-rev-lex matrix; is that right?

• expect as input a matrix M (over ring of char 0, whose entries are integers) of full (row) rank where each col is either zero or the first non-zero element is positive
• result is a (full rank) square matrix defining a term ordering whose first rows are equal to those of M

The fn gives error if the input conds are not satisfied.

Comments? Criticisms? Other ideas?

John Abbott wrote:

I suggest that the semantics of NewMatCompleteToOrd be the following:

yes, I agree.
I'm just a bit undecided about the QQ/ZZ choice: originally it was ZZ, but then I changed the code so that it would accept QQ (and the rank is indeed computed in QQ). I'm a bit concerned about changing back..

John Abbott wrote:

The CoCoALib name is NewMatCompleteToOrd while in CoCoA-5 it is CompleteToOrd.
Is this what we want?

I was following the cocoalib rule of "New" when creating a new matrix, but I didn't like it in cocoa-5.
... but you are right: that's not nice.

I am pretty convinced that ZZ is the right ring for order matrices in CoCoALib.

That said, I am making sure that the functions accept matrices over any ring of char 0, but the entries must be integer. If you ask a poly ring (or PPMonoid for its order matrix, what you get back is a matrix over ZZ).

Not having a matrix over QQ is a nuisance if you want to compute its inverse, but it is fairly easy to convert it to a matrix over QQ by using apply with an embedding homomorphism (ZZ --> QQ).

I also had to change some tests which compared the result of OrdMat to a given matrix (which by default is over QQ); I felt that the changes were not too burdensome, though it was nicer not to have to specify the ring... but that's a consequence of our "unnatural choice" that a matrix constructed explicitly from a list of lists of integers is taken to be over QQ...

I shall shortly try to implement the semantics given in comment 4 above.

After speaking to Anna, the idea is that only NewMatCompleteToOrd will remain publicly visible; the other fns will either be removed or hidden from public access.

For the time being the precise definition of the single function will be deliberately a bit vague, so we have some leeway in completing a matrix to an ordering.

John Abbott wrote:

Perhaps MakeTermOrd or MakePositiveTermOrdering, or something similar?

MakeTermOrd!