Combinatorial designs: add some difference matrices and related objects

[gh-Ivo-Maffei]

We add a few constructions of difference matrices whose lambda parameter is not 1.

We then modify the orthogonal arrays and transversal designs constructions to take advantage of these additions. Finally, we add a new function symmetric_net.

[dimpase]

I see failing doctests:

sage -t --warn-long 94.4 src/sage/combinat/designs/latin_squares.py  # 2 doctests failed
sage -t --warn-long 94.4 src/sage/combinat/designs/designs_pyx.pyx  # 3 doctests failed

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​6c362d8

fixed old doctests and bugs

[dimpase]

Do you run tests using GitHub Actions? (see #29401 for details)

In your code, to build docs, one needs

src/sage/combinat/designs/orthogonal_arrays.py

@@ -80 +80 @@
       Set to ``True`` by default
 
     - ``existence`` -- bolean. Instead of returnig a symmetric net, return:
-      - ``True`` -- such a net can be constructed by Sage
-      - ``False`` -- no such a net exists
-      - ``Unknown`` -- Sage does not know how to build such a design
-        so such design may or may not exist
+        - ``True`` -- such a net can be constructed by Sage
+        - ``False`` -- no such a net exists
+        - ``Unknown`` -- Sage does not know how to build such a design
+          so such design may or may not exist
 
     EXAMPLES::
 

src/sage/combinat/designs/difference_matrices.py

@@ -428 +428 @@
     - ``g,k,\lambda`` -- (integers) parameters of the difference matrix to construct
 
     - ``existence`` -- (boolean) instead of building the design, return:
-      - ``True`` if Sage can build the difference matrix using the subgroup construction
-      - ``False`` if Sage can't build the difference matrix using this construction
-         Note that Sage may be able to build such difference matrix in other ways
+        - ``True`` if Sage can build the difference matrix using the subgroup construction
+        - ``False`` if Sage can't build the difference matrix using this construction
+          Note that Sage may be able to build such difference matrix in other ways
 
     EXAMPLES::
 

(sphinx is very sensitive to correct indentation)

[mkoeppe]

Batch modifying tickets that will likely not be ready for 9.1, based on a review of the ticket title, branch/review status, and last modification date.

[slelievre]

One occurrence of "more than 1 time" should be "more than once" as elsewhere.

Can you do a round of pep8 formatting?

I would use lamda as an alternate name for lambda (since lambda is a reserved keyword in Python). I find it makes code easier to read than lambd or lmbda.

[slelievre]

Replying to slelievre:

I would use lamda as an alternate name for lambda

Another option is la which I like too.

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​f22eec1	All changes to this new branch
​371e4c9	removed garbage code and cleaned some whitespaces
​d3550ca	removed more whitespaces and typos
​b0b020a	fixed trivial cases and BIG mistake
​0547de1	fixed old doctests and bugs
​f9bdc65	fixed doc string
​07f6a79	subgroup construction handles 'any' group; some code formatting
​59d1be9	some more formatting
​b3c3bd5	fixed docstring; added GAP group to subgroup constructions; group_law; is_difference_matrix

[gh-Ivo-Maffei]

I did some more work on the "subgroup_construction" method and added support for GAP groups in other places. Sage's tests pass and the documentation builds without errors. However, I've probably missed some formatting issues here and there.

lmbda is the keyword used throughout the "designs_pyx.pyx" and the "difference_matrices.py" files. I introduced it only in the "orthogonal_arrays.py" file. If it bothers you, then I'll change it in all three files as I believe it should be consistent across them.

Finally, the definition of difference matrices in the doctoring doesn't seem right and needs some checking.

[gh-Ivo-Maffei]

I looked into the definition of difference matrices.
The book "Design Theory" by Beth et. al. (Cambridge University Press, 1999) defines a (g, k, \lambda) difference matrix as a k \times \lambda g matrix such that for any two distinct rows R_i, R_j each element of G appears \lambda times in the sequence (R_i[l]-R_j[l]). This is basically, the definition given in the docstring, but the dimensions of the matrix are flipped (hence the docstring is wrong).
The docstring in is_difference_matrix, gives the same definition without specifying the dimensions. What the codes actually do is redirecting the call to is_quasi_difference_matrix which, in this specific case, checks that in any 2 columns C_i, C_j each element of G appears \lambda times in the sequence (C_i[l] - C_j[l]). However we need G to be Abelian since the code doesn't check both C_i - C_j and C_j - C_i.

So there are 2 issues to fix:

1. change the docstring of difference matrices to use columns or change the code by taking transposes when needed;
2. limit difference matrices to Abelian groups or change the is_quasi_difference_matrix function to allow for non-Abelian groups

Personally, I would change the docstring for the difference matrices so that it matches the definition of quasi-difference matrices and then change the code of is_quasi_difference_matrix to allow for non-Abelian groups. Are there any reasons I should not go this way?

[dimpase]

do you meanwhile have non-trivial examples of difference sets for non-abelian groups?

[dimpase]

I think changing the docstring is the obvious best option - as it does not break any code.

In the non-abelian case, do you still use additive notation for the group? This is unusual, perhaps needs commenting...

[gh-Ivo-Maffei]

While there exist non-abelian difference sets (e.g. ​http://mathonline.wikidot.com/difference-sets-in-non-abelian-groups), the difference_family function explicitly states that it only returns difference families for abelian groups.

As far as the notation is concerned, it seems standard to use + and - for difference matrices despite I haven't found any definition that restricts to abelian groups. If we end up allowing non-abelian groups, then I'll add a note in the docstrings.

[mkoeppe]

Setting new milestone based on a cursory review of ticket status, priority, and last modification date.