Gröbner basis project
Codebase for research into Gröbner basis computation
Todo List
page DynGB: Dynamic Gröbner basis project files

These are the highest priority items: things I think are needed before I’d call it “ready.”

  • Organize files into directories.
  • General improvements to efficiency based on profiling. (ongoing)
  • Implement simplex solver as oracle for DDM, compare with DDM (idea due to D. Lichtblau).
  • Optimize length() in Polynomial_Linked_List.
  • Add Fukuda and Prodon’s cdd as an LP_Solver. [6]
  • Bring polynomial iterators in line with C++ convention.
  • Implement other C++11 modernizations (auto, noexcept, override, …).
  • Generalize/improve the memory manager.
  • Add PPL as an LP_Solver. [1]
  • Implement Caboara’s examples.
  • Implement graded Hilbert numerators.
  • Implement or link to a simplex solver, compare with DDM.
  • Determine what's wrong with the \(4\times4\) system. (Turns out nothing was wrong: the system is simply not amenable to polyhedra.)
  • Implement a global analysis at the beginning of the algorithm.
  • Implement Hilbert polynomials using multiple-precision arithmetic. (Denominators get too large for long long!!!)

These items would be nice, but aren’t a big deal for me at present.

  • Improve rings and fields:
    • Create a general Ring class.
      • Build polynomial rings off rings, not off fields. This could be difficult, since we typically want polynomials to have invertible coefficients. It doesn’t seem strictly necessary, though: S-polynomials and top-reductions, for instance, can be computed by multiplying by the leading coefficient of the other polynomial, rather than by dividing by one’s own coefficient.
      • Implement Dense_Univariate_Integer_Polynomial as a proper Polynomial representation.
      • Create a general Euclidean_Ring class. Add to it the divide_by_common_term() function.
    • Create a general Field class.
  • Reimplement Double_Buffered_Polynomial so its arrays contain pointers to Monomial, rather than an expanded Monomial. See if that changes things.
  • Re-examine what’s going on with masks, since the plus to efficiency doesn’t seem worth the effort.
  • Implement marked polynomials with a dynamic algorithm that works practically in the grevlex order, with the marked term being the true leading monomial. This may be very inefficient to reduce.
  • Implement a Dictionary_Linked_Polynomial class, where any term points to one unique instance of a monomial, rather than having many copies of monomials in different polynomials. Upside is that equality test during canonicalization is instantaneous (compare pointers). Downsides may include finding/sorting the monomials, indirection.
  • Detach monomial ordering from monomials, since caching ordering data doesn’t seem to help much?
  • Implement a Polynomial_Builder class to help build polynomials more easily by reading from an input file. That way we don’t have to write a fresh control program for each example system. (see user_interface())
  • Implement an Indeterminate class and a Polynomial_Builder class to help build polynomials more easily.

I’m not sure these are worth doing.

  • Most skeleton code seems to have little overhead, so most “improvements” related to that falls here:
    • Implement DDM with the Fukuda-Prodon criterion, compare to Zolotykh’s.
    • Implement Roune’s algorithms for Hilbert functions.
    • Compare each potential PP with all other potential PP’s, reducing the number of false positives. [This does not seem to be necessary at the moment, as the overhead is quite small, but it is still a thought.]
    • Add a hash mechanism to the constraint class to help avoid redundnacy.
  • Create a Matrix_Ordering_Data class as a subset of Monomial_Order_Data.
  • Add an insert() function to Monomial_Node to insert another Polynomial_Linked_List, subsequently to be destroyed.
  • Think about computing all inverses of a small prime field immediately at startup.
  • Test matrix orderings more thoroughly.