CoCoA » CoCoA-5

(Added myFieldNamesStrings in Interpreter.[CH] for Record)

/**/ indent(NormalizComputation(Record[AnnaINT := 4, JohnRingElem := x], ["hallo"]));
Record[
  OneFieldWas := "AnnaINT",
  hallo := 0,
  recognizedA := 4,
  recognizedJ := x
]

I've found an easier way to make a RecordValue (why didn't I think of it before?):
instead of making a new field using "new BlahValue(Blah)" use "Value::from(Blah)".

Further improvement of error message:

# NmzComputation(Record[ integral_closure := [[1,2],[2,1]] ],["HilbertBasis"]);
ERROR: Expecting type MAT as field "integral_closure" of the record, but found type LIST
NmzComputation(Record[ integral_closure := [[1,2],[2,1]] ],["HilbertBasis"]);
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Since the HilbertSeries is now availabe in CoCoALib, I also added it to NmzComputation. Example:

Cone1 := Record[ integral_closure := Mat([[1,2],[2,1]]) ];
NC1 := NmzComputation(Cone1, ["HilbertBasis", "SupportHyperplanes", "HilbertSeries"]);
indent(NC1);

Record[
  HilbertBasis := [[1, 1], [1, 2], [2, 1]],
  HilbertSeries := Record[DenFactors := Record[RemainingFactor := 1, factors := [-t +1, -t^3 +1], multiplicities := [1, 1]], num := t^2 -t +1],
  SupportHyperplanes := [[-1, 2], [2, -1]]
]

Also: the function first look what was asked and then compute everything in one Normaliz computation.

edit: Anna pointed out that the ZZ at creating the Matrix is not needed.

And it also works with gradings:

Cone2 := Record[ integral_closure := Mat([[1,2],[2,1]]), grading := Mat([[2,1]])];
NC2 := NmzComputation(Cone2, ["HilbertBasis", "SupportHyperplanes", "HilbertSeries"]);
indent(NC2);

Record[
  HilbertBasis := [[1, 1], [1, 2], [2, 1]],
  HilbertSeries := Record[DenFactors := Record[RemainingFactor := 1, factors := [-t +1, -t^20 +1], multiplicities := [1, 1]], num := t^18 -t^17 +t^15 +t^10 -t^9 +t^8 +t^3 -t +1],
  SupportHyperplanes := [[-1, 2], [2, -1]]
]

Which example do you mean? For me all the newer ones (from update 10 on) are working. The older should work too if you replace NormalizComputation by NmzComputation. I tested it with the latest CVS.

Maybe I have to give you an updated libnormaliz? I will email it.

Some explanation on NmzIntegrate:

The possible input is basically the same as for Normaliz. This means the cone record can have as fields the names of the entries of libnormaliz::InputType (to be found in libnormaliz.h), i.e.
integral_closure,
polyhedron,
normalization,
polytope,
rees_algebra,
inequalities,
strict_inequalities,
signs,
strict_signs,
equations,
congruences,
inhom_inequalities,
dehomogenization,
inhom_equations,
inhom_congruences,
lattice_ideal,
grading,
excluded_faces
For an extended description of the input types see the Normaliz manual.
As compute options you can give any libnormaliz::ConeProperty.
The conversion of the strings to the enum types is done by libnormaliz functions. This ensures that the NmzComputation always includes the full range of functionality of libnormaliz.
BUT at from the ConeProperty s at the moment only
HilbertBasis
SupportHyperplanes
Deg1Elements
HilbertSeries
are working. The others do not have a matching return function. I will work on that. To do is:
1) Implement additional return functions in CoCoALib.
2) Let NmzComputation return everything that is computed (? Is this the desired behaviour? I think so.)
3) Implement NmzComputation(Cone). This is easy when the other two points are done.

One point why I did not work on 1) earlier was that I wonder if there is a more systematic way than make a copy&paste and replace just the name of the ConeProperty. But I think there is not.

I have implemented point 1) (see #218) and now also point 2). I will send the code.

For 3) I have the problem that I do not know how to overload CoCoA5 functions with a different number of parameters. The naive way did not work.

Christof Soeger wrote:

I have implemented point 1) (see #218) and now also point 2). I will send the code.

tested and cvs'ing now

For 3) I have the problem that I do not know how to overload CoCoA5 functions with a different number of parameters. The naive way did not work.

no, there's no naive method :-(
It is actually a bit fiddly. See for example the definition of coefficients.

// variable number of args
DECLARE_ARITYCHECK_FUNCTION(coefficients) { return (1<=nArg) && (nArg<=2); }
DECLARE_BUILTIN_FUNCTION(coefficients) {  // AMB
    invocationExpression->checkNumberOfArgs(1,2);// variable number of args
        (...)
        if (invocationExpression->args.size()==1)
        (...)
}

Okay, that's not so difficult if you know how it works. I just had to remember also to remove the matching END_STD_BUILTIN_FUNCTION.

@Christof: is this issue resolved/complete/closable???

added Value::from(QuasiPoly).
... keep in mind that indices in the LIST representing a QuasiPoly start from 1 in CoCoA-5 (and from 0 in C++/CoCoALib/libnormaliz)

• put the first entry of the quasi-poly last in CoCoA-5
• make a quasi-poly become an "indexable object" (as used for "lists of indets" all with the same head)

John Abbott wrote:

The "shifting" of the indices by 1 could be awkward. I can think of two ways to resolve the matter:

• put the first entry of the quasi-poly last in CoCoA-5
• make a quasi-poly become an "indexable object" (as used for "lists of indets" all with the same head)

We have lots of cases with awkward shifting (i.e. CoeffListWRT). Why should this be different from the others?
[in case we need to discuss about this topic, we'd better make a "indexing from 1 or from 0" issue]

I think this is different because the mathematical structure is indexed by elements of ZZ/(n) rather than indices 1,2,3,...; so index 0 is also equivalent to index n, which is why I proposed simply moving the first entry to the last position.

@Christof: What do you think?

I'm unsure. I think in any case we also need an evaluate function like in the library. We have to rewrite it anyway, so from that point it is not relevant.
So I think it is about how it is printed. Take the example from the manual

Cone := Record[ integral_closure := Mat([[1,2],[2,1]]),
                grading := Mat([[2,1]])];
NC2 := NmzComputation(Cone, ["HilbertBasis", "SupportHyperplanes", "HilbertSeries"]);
indent(NC2.HilbertQuasiPolynomial);

For the Evaluate function in C5 is there a convention how to do it?

I implemented a NmzEvaluateHilbertQuasiPolynomial method. It is very close to the implementation for QuasiPoly in cocoalib. Now you can do

NmzEvaluateHilbertQuasiPolynomial(NC2.HilbertQuasiPolynomial,0);
NmzEvaluateHilbertQuasiPolynomial(NC2.HilbertQuasiPolynomial,1);

The name of the function is not yet optimal. Also, as QuasiPoly is a general cocoalib type and independent of libnormaliz, this function should be so. I will send the code, feel free to put it somewhere else under a different name! I will then update the documentation for NmzComputation.

EDIT:
For the name I suggest EvalQuasiPoly