Project

General

Profile

Design #1649

Add file SparsePolyOps-vector.C

Added by Anna Maria Bigatti over 2 years ago. Updated about 1 month ago.

Status:
Closed
Priority:
Normal
Assignee:
Anna Maria Bigatti
Category:
Tidying
Target version:
CoCoALib-0.99850
Start date:
21 Jan 2022
Due date:
% Done:

100%

Estimated time:
5.01 h
Spent time:
4.55 h

Description

Add file SparsePolyOps-vector.C with functions interreduced (now in SparsePolyOps-interreduced.C) and syz(vector) (new)

Related issues

Related to CoCoALib - Bug #1641: gcd does not recognize univariate input Closed2021-12-20

Related to CoCoALib - Feature #1488: BuiltIn Interreduce-FunctionClosed2020-09-15

Related to CoCoALib - Design #1720: DivAlg in CoCoALibNew2022-12-21

Related to CoCoALib - Design #1414: Make class RingElemVector?In Progress2020-02-12

History

#1 Updated by Anna Maria Bigatti over 2 years ago

  • Related to Bug #1641: gcd does not recognize univariate input added

#2 Updated by Anna Maria Bigatti about 2 years ago

I think we should call this SparsePolyOps-VectorRingElem.C, or SparsePolyOps-RingElems.C (too subtle, I fear)

add here:
syz
DivAlg

move here:
NR
reduce
IndetsProd
IndetsIn
(taking a std::vector<RingElem>)

and also:
CoefficientsWRT (returning vector)?
CoeffVecWRTSupport ..
(returning a std::vector<RingElem>)

With all these, it still remains a reasonably small file.

#3 Updated by Anna Maria Bigatti about 2 years ago

  • Category set to Tidying
  • % Done changed from 0 to 20

In SparsePolyOps-RingElem we also have:

FindReducerIndex
ReduceActiveLM
reduce

Should these go in SparsePolyOps-VectorRingElem or SparsePolyOps-reduce?

#4 Updated by Anna Maria Bigatti about 2 years ago

  • Category deleted (Tidying)
  • % Done changed from 20 to 0

I think we should call this SparsePolyOps-VectorRingElem.C, or SparsePolyOps-RingElems.C (too subtle, I fear)

add here:
syz ----> no: must stay in submodule
DivAlg v ---> to be improved (see Nicolas Jagersma code using GPoly)

move here:
NR v
reduce v
IndetsProd v
IndetsIn v
(taking a std::vector<RingElem>)

and also:
CoefficientsWRT (returning vector<CoeffPP>) v
CoeffVecWRTSupport .. (returning a std::vector<RingElem>) v

With all these, it still remains a reasonably small file.

Anna Maria Bigatti wrote:

In SparsePolyOps-RingElem we also have:

FindReducerIndex
ReduceActiveLM
reduce

Should these go in SparsePolyOps-VectorRingElem or SparsePolyOps-reduce?

(talking to myself)
At the moment SparsePolyOps-reduce contains reduce-related operations, but quite technical/internal (using GPoly and Reductors types).

Now my preference is to keep these 3 functions for "public use" together with the vector-functions. (i.e. "vector<RingElem>" wins over "reduce-related")

#5 Updated by Anna Maria Bigatti about 2 years ago

Anna Maria Bigatti wrote:

syz

even though this was the start of this topic, Syz of a vector should go in submodule.C, because returns a module.

#6 Updated by John Abbott about 2 years ago

  • Category set to Tidying
  • Status changed from New to In Progress
  • % Done changed from 0 to 10

It seems that Anna accidentally reset the progress for this issue... maybe she had two browser tabs on the same issue?

I vote against SparsePolyOps-ringelems.C: just 1 letter difference is too little!

It is not clear to me where syz should go.
No doubt we have other functions which take inputs of one type and return a result of another.
On the whole it seems more natural to me for the functions to be groups according to the type of
parameter that they expect. If we had better documentation for CoCoALib then this would be less
of an issue: e.g. the user could ask for "all functions returning module".

#7 Updated by Anna Maria Bigatti about 2 years ago

  • % Done changed from 10 to 60

Checked in.
Changed version numer to 719 (very close to the official 720)

Now the file contains the division related functions.

#8 Updated by Anna Maria Bigatti about 2 years ago

  • Target version changed from CoCoALib-0.99800 to CoCoALib-0.99850

I don't want to make hasty decision now, so this ("division related") is the state for release 0.99720.

Postponing other decisions for next version.

#9 Updated by John Abbott about 2 years ago

#10 Updated by Anna Maria Bigatti about 2 years ago

We decided syz to be in submodule.C. Checked in.

#11 Updated by Anna Maria Bigatti over 1 year ago

#12 Updated by John Abbott about 1 month ago

  • Status changed from In Progress to Feedback
  • % Done changed from 60 to 90

#13 Updated by Anna Maria Bigatti about 1 month ago

  • Status changed from Feedback to Resolved

Add syz and syz0 (allowing 0s) for vector of RingElem

#14 Updated by Anna Maria Bigatti about 1 month ago

  • Related to Feature #1206: syz, SyzOfGens: which shifts for zero? added

#15 Updated by Anna Maria Bigatti about 1 month ago

  • Status changed from Resolved to Closed
  • % Done changed from 90 to 100

Anna Maria Bigatti wrote:

Add syz and syz0 (allowing 0s) for vector of RingElem

syz should stay in submodule.C, non in SparsePolyOps-vector.

Closing this issue: the file has been added and already hosts some functions.

#16 Updated by Anna Maria Bigatti about 1 month ago

  • Status changed from Closed to Resolved
  • % Done changed from 100 to 90

After closing I realized that the "coefficients" functions were missing and that the .H files were not aligned.
Still working on this.

#17 Updated by Anna Maria Bigatti about 1 month ago

After trying to rearrange the header files I found this problem.
There are functions on vectors of RingElem need headers of RingElem functions, and viceversa. But I find it disturbing to have the cross include of the two H files in both.

I suggest having all headers in SparsePolyOps-RingElem.H (well indicated) and the "vector functions" in the dedicated SparsePolyOps-vector.C, just for convenience.

#18 Updated by Anna Maria Bigatti about 1 month ago

Anna Maria Bigatti wrote:

I suggest having all headers in SparsePolyOps-RingElem.H (well indicated) and the "vector functions" in the dedicated SparsePolyOps-vector.C, just for convenience.

I tried, and I'm satisfied: some includes are necessary only for the "vector-functions" so the separation of the C files looks meaninful, not just "convenience". On the other hand, one single H file is convenient for practical usage.

#19 Updated by John Abbott about 1 month ago

#20 Updated by Anna Maria Bigatti about 1 month ago

  • Status changed from Resolved to Closed
  • % Done changed from 90 to 100

#21 Updated by Anna Maria Bigatti about 1 month ago

  • Estimated time set to 5.01 h

#22 Updated by Anna Maria Bigatti about 1 month ago

  • Related to deleted (Feature #1206: syz, SyzOfGens: which shifts for zero?)

Also available in: Atom PDF