GSoC 2026 – Groebner bases project direction and related areas
Tanishka Wagh
Hi everyone,
I’m Tanishka Wagh, a third-year student studying Computational Mathematics (ECSOE) and Data Science & Programming (IIT Madras). I’ve worked on a course project involving Groebner bases and solving systems of polynomial equations, and I’m comfortable with Python, though still gaining experience with larger long-term codebases.
I’ve been reading through the `sympy/polys` module and looking at the GSoC idea on efficient Groebner bases and their applications. From what I understand, the current implementation includes Buchberger, F5B and FGLM, while several directions (e.g. F4, sugar strategies, Groebner walk, etc.) are still open.
I had two main questions:
-
The idea page mentions previous related work, could someone point me to which past project(s) this refers to?
I noticed that a lot of current work in `polys` seems focused on type annotations and infrastructure improvements. How does Groebner-basis work fit into current priorities, and are there particular entry points that would be helpful to start with?
I’m mainly interested in the Groebner/polys direction, but while exploring I also noticed the computational group theory roadmap in the combinatorics module. If one of these areas currently has clearer contribution opportunities or more active development, I’d really appreciate guidance.
Thanks,
Tanishka
Oscar Benjamin
>
> Hi everyone,
Hi Tanishka,
> I had two main questions:
>
> The idea page mentions previous related work, could someone point me to which past project(s) this refers to?
blame will lead you to the past pull requests and issues.
> I noticed that a lot of current work in `polys` seems focused on type annotations and infrastructure improvements. How does Groebner-basis work fit into current priorities, and are there particular entry points that would be helpful to start with?
particular I think implementing the F4 algorithm would be good. There
is already some code for sparse RREF (with division and also
fraction-free) with DomainMatrix that could be used as a starting
point.
Another thing that would be very useful is having interfaces that can
efficiently store a Groebner basis and compute a new basis for the
initial basis plus one extra polynomial sort of like this:
In [6]: gb = groebner([x**2 - 2, y**2 - x], [x, y])
In [7]: gb2 = groebner(list(gb) + [z*x - y], [z, x, y])
Computing gb2 from gb is what is needed to implement exact division in
a polynomial ring modulo a system of polynomial equations which is a
primitive operation for fraction-free algebra over such rings. It can
be done much more efficiently than computing a Groebner basis fully
from scratch each time but an interface/implementation for that is
needed.
--
Oscar
Tanishka Wagh
hi Oscar,
as advised, ive been going through the `DomainMatrix` implementation and the underlying `DDM` / `ddm_*` routines to understand how linear algebra is currently handled, especially the RREF-related parts. ive also submitted my application and am very interested in working on this project. :)
i did however have a question about how best to structure an F4 implementation on top of this.
right now, the matrix routines seem to follow a fairly stateless pattern (construct then reduce then return), without exposing any reusable intermediate structure (like partially reduced matrices or persistent row-echelon form). given that, im trying to understand where it makes the most sense to handle reuse.
Would it be better to:
- treat `DomainMatrix` as a black-box linear algebra backend (i.e. construct Macaulay matrices and call `rref` each time), or
- consider extending it to support some form of incremental or reusable reduction?
wrt that, for incremental Groebner basis updates (going from `gb` to `gb2`), would reuse typically live at the polynomial level (e.g. critical pairs, basis structure), rather than in the linear algebra layer?
im trying to get a clearer picture of where state should live in this design.
Thanks,
Tanishka