W.Bruns's wish list
Dear Anna and John,
let me collect all the points that came up in the development of nmzIntegrate (Christof has everything and can show it to you):
1) Input of polynomials. We have made such a function for nmzIntegrate, but is not good for general use.
2) A default constructor for RingElem. Not absolutely necessary, but makes programming easier.
3) Coefficients and power products should automatically be considered as polynomials for arithmetic. This is too natural for every mathematician.
4) Spaces separating terms of polynomials?
5) A simpler solution for using OpenMP
6) Nice conversion from coefficients of polynomials to integers and rationals that can be used outside CoCoA (for example in Normaliz).
7) More liberal treatment of external libraries by avoiding hardwired paths
8) Function for homogeneous components (nmzIntegrate contains a function for standard gradimg)
9) Standard grading of polynomial rings by default
10) At one point you ask whether one should use the term "multiplicity" in connection with factorization. I think this is the right choice. I think you are using "exponent" at present.
11) One could think of a clean up function for polynomials in the following sense: suppose I build a polynomial by freely using PushBack without paying attention to the monomial order. Then I could run such a function to sort the terms and convert my wild list into a correct polynomial.
#4 Updated by John Abbott over 5 years ago
There is a new configuration option
--threadsafe-hack which activates the CoCoALib compilation flag
As the name suggests it is only a hack, and should not be relied upon to produce robust, leak-free code. We do hope eventually to make a proper threadsafe version of CoCoALib.
This resolves Bruns's point (5).
#5 Updated by John Abbott over 5 years ago
I have changed the name of a field in a
factorization object: it is now
myMultiplicities rather than the previous
myExponents. An analogous change has been made to the record produced by factorization functions in CoCoA-5: the field is now called
Multiplicities rather than
This resolves Bruns's point (10).
#9 Updated by Winfried Bruns 12 months ago
An issue I stumbled on recently is 3) from my wish list. I think it is not yet implemented. Suppose I produce a polynomial from a monomial M (with coefficient) by substituting polynomials for the indeterminates in the monomial and then I want to multiply this new polynomial by the coefficient of M ...
Also 6) can cause headache.
#10 Updated by John Abbott 12 months ago
- % Done changed from 0 to 50
Task (6): convert a ringelem to an integer or rational should be fairly easy via
here is a simplistic example of the syntax...
RingElem x(R); ... BigInt N = ConvertTo<BigInt>(x); BigRat q = ConvertTo<BigRat>(x);
Task (3): automatic (homomorphic) mapping of ring elems is high on my list of desirable features, but may take a long time to do correctly. Currently the approach I use is the following:
PolyRing P = ...; RingHom coeff = CoeffEmbeddinghom(P); RingElem f(P); ... f = f/coeff(lc(f)); // make f monic
In words: I create a RingHom (with a helpful name) and then apply it explicitly where it is needed. I know this is far from ideal, but I think it is not too onerous as a workaround.