Singular

Hi!

First, the mathematical background of my computations: The rings I'm dealing with are modular cohomology rings of finite groups. In Singular, it can be expressed as a quotient of a commutative (char. 2) respectively super-commutative (char.>2) ring R modulo an ideal id that is (weighted) homogeneous with respect to the degrees of the variables of R.

A weighted homogeneous element f of R/id (represented by F in R) is called "filter regular", iff the kernel of the multiplication map by f (i.e., the annihilator of ideal(f) in R/id) is finite dimensional. It is known that R/id has a filter-regular system of parameters f1,f2,... , i.e., R/id is finite dimensional over the algebra generated by the parameters and the multiplication map of the i-th parameter of (R/id)/(all previous parameters) has finite dimensional kernel. Actually some homological algebra construction explicitly yields such parameters.

Now, some formula turns the dimensions of the annihilators and of (R/id over the parameters) into the so-called "filter degree type", that is independent of the choice of f1,f2,.... There is a conjecture of Dave Benson on the filter degree type of modular group cohomology rings that is proven for some type of finite groups and a weaker version of the conjecture holds true in general. I'd like to verify the conjecture in a potential counter example (here, there will be five parameters and at least the first one is actually a regular element).

So, basically I want to compute
Unfortunately, the explicit construction yields filter regular parameters in very high degrees, making the computation unfeasible. So I try to enumerate potential parameters in smaller degrees. Here, the computation seems feasible, but takes very long (several days for each parameter candidate), and I am seeking help to eventually make it quicker.

My observation from other cohomology rings: It is a good idea to replace by a small computation using
Actually it is even better to replace the intersect command by some self-made procedure that uses a Hilbert driven Gröbner basis computation to compute the intersection, since the first Hilbert series is relatively easy to compute IN MOST EXAMPLES. Unfortunately, in the interesting example, the computation of the first Hilbert series yields an int overflow. It takes about 8 hours to compute the quotient via ``intersect(id,ideal(F))`` in a Hilbert-free way.

Questions:
1. Is the int overflow something I have to live with, or could there possibly be a way around?
2. Independent of the potential counter example (which is commutative): Mathematically, the Hilbert series would also be defined in the graded commutative case. But can Singular compute it in that case?

Next problem is to compute ``groebner(modulo(q,id))``. Here, I don't know yet how long it will take. But I have seen in the manual that there also is ``moduloSlim``. Is there any heuristics that could tell which command fits better to my situation? In particular, is one of them better suited for weighted homogeneous data?

And last but not least: Is there perhaps a specialised faster command in Singular that would return ``groebner(modulo(quotient(id,ideal(F)), id))``?

Best regards,
Simon

Actually, what I am really interested in is the vector space dimension in each degree, i.e., where , rw is the list of degrees of the variables of R, qw is the list of degrees of the elements of q, and d is some degree.

And I wonder: Is it perhaps possible to compute these dimensions without explicitly computing groebner(modulo(quotient(id,ideal(F)), id)) and weightKB(...)? Perhaps you see some argument based on Hilbert functions?

Best regards,
Simon

I think I solved it.

It seems indeed easy to compute the data I'm interested in using Hilbert functions: It is a straight forward application of Lemma 5.1.2.(3) in the "Singular introduction to commutative algebra". So, if I see that correctly, I actually don't need to compute quotient(...) and modulo(...) at all. That'd be great, because it means to cut down the computation from several days per example to a few minutes per example.

Concerning "hilbert driven approach to compute the quotient": The int overflow in the computation of "hilb(id,1)" is real (i.e., is not the result of a bug). I was able to compute it with Sage, and it turns out that some of the coefficients are indeed bigint.
-> A question remains:
Can one make Singular use bigint vectors for hilb(id,1)?

Concerning "modulo versus moduloSlim": In my main example, modulo was at least 12 hours faster than moduloSlim. But I have of course no idea if that's a general rule for weighted homogeneous input.

Kind regards,
Simon