Project

General

Profile

Feature #253

W.Bruns's wish list

Added by John Abbott almost 6 years ago. Updated about 1 year ago.

Status:
In Progress
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
04 Oct 2012
Due date:
% Done:

50%

Estimated time:
Spent time:

Description

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.


Related issues

Related to CoCoALib - Feature #221: Better RingElemsClosed2012-08-08

Related to CoCoALib - Support #234: Update/Improve geobucket documentationClosed2012-09-25

Related to CoCoALib - Feature #223: Automatic mapping of RingElemsClosed2012-08-08

Related to CoCoALib - Feature #222: Printing polynomials - spaces between termsIn Progress2012-08-08

Related to CoCoALib - Feature #209: ReadExpr: input polynomials in CoCoALibClosed2012-07-24

Related to CoCoALib - Feature #233: AsINT and AsRAT -- ConvertTo<BigInt> and ConvertTo<BigRat>Closed2012-09-25

Related to CoCoALib - Feature #224: Leading formClosed2012-09-03

Related to CoCoA - Feature #247: Use gmp default location if possibleClosed2012-09-17

Related to CoCoALib - Support #256: Improve doc about ordering/grading for poly ringsIn Progress2012-10-08

Related to CoCoALib - Feature #342: Remove denominators: QQ[x] -> ZZ[x] (and PushBack(coeff, PP))Closed2013-04-17

Related to CoCoALib - Feature #407: RingElem ctor from mpz_t (from Bruns)Closed2013-10-12

Related to CoCoA - Support #425: Osnabrueck 2014-01Closed2014-01-27

History

#1 Updated by John Abbott almost 6 years ago

Implemented Bruns(10): "multiplicity" instead of "exponents" in factorization

#2 Updated by Anna Maria Bigatti almost 6 years ago

  • Subject changed from Bruns's wish list to W.Bruns's wish list

#3 Updated by Anna Maria Bigatti almost 6 years ago

  • Status changed from New to In Progress

#4 Updated by John Abbott almost 6 years ago

There is a new configuration option --threadsafe-hack which activates the CoCoALib compilation flag -DCoCoA_THREADSAFE_HACK.

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 almost 6 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 Exponents.

This resolves Bruns's point (10).

#6 Updated by John Abbott almost 6 years ago

Closed issue #247 has satisfied wish (7).

#7 Updated by John Abbott about 3 years ago

Can we finish this issue in the near future?

#8 Updated by Anna Maria Bigatti about 1 year ago

  • Project changed from CoCoA to CoCoALib
  • Target version set to CoCoALib-0.99999

This issue was under "CoCoA" instead of "CoCoALib".
I'm recovering these old and forgotten issues, so we reconsider them.

#9 Updated by Winfried Bruns about 1 year 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 about 1 year ago

  • % Done changed from 0 to 50

Task (6): convert a ringelem to an integer or rational should be fairly easy via ConvertTo:
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.

Also available in: Atom PDF