Use a "Qualified" struct.
The observation is that there are a lot of unnecessary checks that happen in the various stages of an algorithm.
We see check to see if two numbers are zero, then multiply them together, then maybe we check they are zero again, though this is unecessary (if they are in an integral domain) as we know they won't be zero.

This is only one such case. What I propose is a "Qual" struct in which we need to pass our inputs into, it will have Phantom types like "NonZero", which will cause it to check these things.
But only once when it is first created (or maybe in intermediate expressions as well?).
In the end we can then specify more constraints at compile-time to develop more bug-resistent code 

At the moment the "is_groebner_basis" method is implemented for Ideals, but this doesn't really make sense and it should probably be implemented for a collection of generators rather than the ideal.

This collection could be just a vector at the start, but it would be even better if we could give it it's own type.

I want to make Variate an AdditiveMonoid, but this requires me to implement ClosedAdd, which required me to implement both Add and AddAssign for Variate. But I would prefer to use the operate function that is provided in the Abstract Magma definition because then I can use pointers. This is more generally a problem because the AbstractMagma trait should implement Add for &Variate not Variate. Might need to consider making my own types

It would be nice to have an iterator over monomials.
We could then add, subtract and take the gcd and lcm nicer. This would replace the "index_map" function

Want to make a predicate where we always know that polynomials are always in their most simplified form.

If they aren't then perhaps they can be put in a wrapper to indicate that they haven't been checked

Should integrate the Euclidean domain more formally into more areas.
This includes:

• Polynomials
• Integers
• Monomial indices

Of course overall this would be great, but in particular, lots of things like dividing two terms and calling unwrap is causing a lot of issues and needs to be properly addressed

Currently I am using my custom definition of abstract algebras like Groups, Rings etc.
The "alga" crate already has this and it seems to be the standard so it would be good to comply with it.

Look at implementing the Copy trait on Term if Mon and Coeff implement it

At the moment, most of the polynomial ring is typed, except for the variables in the ring.
This is the last step to making the polynomials fully typed and thus allow cleaner code. This will also solve the problem when creating the One and Zero traits for polynomials.

The problem is that the type signature for the "one()" function doesn't take any input because it is constant, this should the be canonical form. But since we need to make the polynomial as an element of an ambient polynomial ring e.g. Z[x, y] we have no way to inform the polynomial that the variables should be $x$ and $y$.

The current solution is to make the one() and zero() functions output a polynomial in a ring with no variables which is working at the moment but it isn't the cleanest solution.

Just do it

The F4 algorithm test only works sometimes, sometimes one of the resulting polynomials in the groebner basis has two terms with the same monomial i.e. it hasn't been fully simplified.

I both: don't know how this can happen, why it only happens sometimes since this program should be fully deterministic, and also why this is breaking the div_poly function since I don' see why it shouldn't continue to work.

We have to do a lot of checked called e.g. for division, for the case where the quotient is zero. It would be interesting to explore the idea of avoiding these checks by first coercing the objects into the unit ideals, i.e. the ring without the zero element.

All the coercion would amount to is checking if the element is zero or not. This has to happen anyway with the checked divisions so you may as well do it at the start.

This could allow for cleaner code since we don't have to write "unchecked" nor unwrap many objects. A function with takes elements from a unit might also output elements of a unit so we could avoid more coercions that way too

Implement the add, Mul, neg, and other standard operations for the polynomial type.
Just make it work for references and you will be fine

What should the gcd and lcm for fields be?

Currently, if given two arguments I just have them returning the first argument.
I can't see any immediate problems with this but it is probably good to come back to this and properly think it through.

Replace the FFT code with a call to FFTW https://docs.rs/fftw/0.6.2/fftw/

The "elementwise_add" function should be implemented on slices, not the polynomials.

This is so I can then use it in more scenarios (the one that started this, is Karatsuba's algorithm in which
everything can be implemented on the slices)

This gives an error if I run it enough times, it gets caught in a loop

cargo test ideals::f4::tests::bench_f4  -- --nocapture