There are two issues (Issues #10 and Issue #12). Consider this a blog-post summarizing the issues and a pointer to possible solutions. @galois60 and @algeboy please read and chime in. I just pull James' latest response as his "solution;" apologies if this is misrepresenting it.
The heart of both issues that we do not have a function that decomposes groups/ tensors as a direct product of groups/ tensors. Indeed this has been a Project ever since James showed me the Project Board in thetensor-space.
Issue #10
Before any changes, tensors would be rewritten over their centroid with the command TensorOverCentroid, assuming the default Cent := true is set. By the way, this intrinsic is in Sylver. For this conversation, this is the relevant piece of code for TensorOverCentroid; you all already understand it.
/* t is a tensor, and we have already checked basic things. */
C := Centroid(t);
J, S := WedderburnDecomposition(C);
...
require IsCommutative(S) : "Tensor is not fully nondegenerate.";
cyclic_check, X := IsCyclic(S);
require cyclic_check : "Centroid must be a commutative local ring.";
require IsIrreducible(MinimalPolynomial(X)) : "Tensor must be indecomposable.";
Note that the last line is a require statement which fails if S is semisimple but not simple.
Now, back to TameGenus, if a user input a group into TGAutomorphismGroup, it was possible for an error to be returned that would say something like "Tensor must be indecomposable.". Admittedly, this shouldn't happen.
TameGenus comes with a number of constructors. In case you're not familiar, let me introduce them. (There's a genus 1 that I'm not going to bother with here.)
TGRandomGroup(q: Int, n: Int, g: Int : Exponentp:=true): GrpPC
This is basically the Universal Coefficients Theorem. It constructs g random, skew-symmetric n x n matrices over GF(q), then writes it over the base field GF(p). This is meant to capture the "pair of forms" perspective we took in the paper. The documentation does not accurately reflect this.
Here you specify the block dimensions, where 1 is assume to be radical. Therefore, RandomGenus2Group(9, [4, 3]) would be a group of order 3^{2(4 + 3 + 2)}. It would have a flat and a sloped block, whose Pfaffian would have degree 2. This constructs the group along the lines of companion matrices, and then it conjugates by a random invertible matrix.
Genus2Group(P: [Poly]): GrpPC
Given a sequence of polynomials, return the group obtained from the perp-decomposition of the tensors (I, C), where C is the companion matrix of a polynomial.
The problem
All three of these constructors can produce decomposable groups. Unless they are decomposable and genus 1, then we actually cannot do anything with them currently.
My last reply isn't so easy to quickly read without the context of the previous comments. So I'll summarize (and possibly add).
I don't think this is a long-term issue. This was brought up because TGAutomorphismGroup couldn't handle an example built from our constructor. Yes, we cannot handle all tame genus groups due to decomposability. Time is too finite for us. If it is particularly egregious for this situation to be present, then I say we either
comment out all constructors until we can decompose tensors
make all our intrinsics internal but document them in the doc, so a user cannot use it without possibly looking at the doc
refuse certain inputs into the above constructors, or do some significant linear algebra before we hand the user the group to make sure it's safe.
Personally, I don't care if our code isn't 100% stable right now; obviously I don't want bugs, and I try to code as best I as possibly can. Of the solutions I've suggested, my preferred one is
to just leave the constructors, document the short-comings, and make the checks in the algorithms smarter without taking more CPU time.
There are two issues (Issues #10 and Issue #12). Consider this a blog-post summarizing the issues and a pointer to possible solutions. @galois60 and @algeboy please read and chime in. I just pull James' latest response as his "solution;" apologies if this is misrepresenting it.
The heart of both issues that we do not have a function that decomposes groups/ tensors as a direct product of groups/ tensors. Indeed this has been a Project ever since James showed me the Project Board in thetensor-space.
Issue #10
Before any changes, tensors would be rewritten over their centroid with the command
TensorOverCentroid, assuming the defaultCent := trueis set. By the way, this intrinsic is in Sylver. For this conversation, this is the relevant piece of code forTensorOverCentroid; you all already understand it.Note that the last line is a require statement which fails if
Sis semisimple but not simple.Now, back to TameGenus, if a user input a group into
TGAutomorphismGroup, it was possible for an error to be returned that would say something like"Tensor must be indecomposable.". Admittedly, this shouldn't happen.Solutions
I'm not going to rewrite solutions, so here's
Issue #12
TameGenus comes with a number of constructors. In case you're not familiar, let me introduce them. (There's a genus 1 that I'm not going to bother with here.)
This is basically the Universal Coefficients Theorem. It constructs
grandom, skew-symmetricnxnmatrices over GF(q), then writes it over the base field GF(p). This is meant to capture the "pair of forms" perspective we took in the paper. The documentation does not accurately reflect this.Here you specify the block dimensions, where 1 is assume to be radical. Therefore,
RandomGenus2Group(9, [4, 3])would be a group of order 3^{2(4 + 3 + 2)}. It would have a flat and a sloped block, whose Pfaffian would have degree 2. This constructs the group along the lines of companion matrices, and then it conjugates by a random invertible matrix.Given a sequence of polynomials, return the group obtained from the perp-decomposition of the tensors (I, C), where C is the companion matrix of a polynomial.
The problem
All three of these constructors can produce decomposable groups. Unless they are decomposable and genus 1, then we actually cannot do anything with them currently.
Solutions
My last reply isn't so easy to quickly read without the context of the previous comments. So I'll summarize (and possibly add).
I don't think this is a long-term issue. This was brought up because
TGAutomorphismGroupcouldn't handle an example built from our constructor. Yes, we cannot handle all tame genus groups due to decomposability. Time is too finite for us. If it is particularly egregious for this situation to be present, then I say we eitherPersonally, I don't care if our code isn't 100% stable right now; obviously I don't want bugs, and I try to code as best I as possibly can. Of the solutions I've suggested, my preferred one is
I look forward to your comments.