Specify the values of k,n in the exceptions

[ncohen]

Simple thing, that can be useful for recursive constructions. You don't always know what "this" design exactly is in complicated functions.

Nathann

[git]

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

​767e091

trac #16388: Specify the values of k,n in the exceptions

[vdelecroix]

Hi Nathann,

All right, why not doing it for BIBD as well?

Vincent

[ncohen]

Indeed. You can add a commit.

Nathann

[vdelecroix]

I can do that, but I do care about merge conflicts with other tickets.

[ncohen]

I can do that, but I do care about merge conflicts with other tickets.

Caring is good. Do you have a specific ticket in mind ?

Nathann

[vdelecroix]

For example #16347 (Wilson's constructions of OA with 2 truncated groups) modifies bibd.py

[ncohen]

For example #16347 (Wilson's constructions of OA with 2 truncated groups) modifies bibd.py

Indeed. You can see that none of the lines near where the exceptions are raised or doctested are touched, so this is safe.

Nathann

[vdelecroix]

The two commits at u/vdelecroix/16388 take care of BIBD. All test pass. Can set to positive review if you like.

Vincent

[ncohen]

Yo !

The two commits at u/vdelecroix/16388 take care of BIBD. All test pass. Can set to positive review if you like.

I added a small commit as one usually writes (v,k,lambda)-BIBD.

Nathann

[git]

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

​a460169	merge Sage version 6.3.beta3
​c365a39	trac #16388: use format for OA + specify (k,n) for BIBD
​ec26ca2	trac #16388: a missing one in BIBD_from_TD
​79178b6	trac #16388: (v,k,1)-BIBD instead of BIBD(v,k,1)

[ncohen]

By the way the modifications you did to the exception of OA/TD will probably cost a LOT of conflicts.

Just mentionning it because you said that you cared.

Nathann

[ncohen]

Oh, my mistake. Those modifications cannot hurt more than the patch did before you wrote this commit. Sorry for that.

I hope I had conflicts in mind when I first wrote it. Otherwise I will pay it.

Nathann

[vdelecroix]

The terminology is not understandable:

• MOLS(n,k) but TD(k,n)
• (v,k,lambda)-BIBD but TD(v,k,lambda)

good luck for your future merges... (now you are used to it ;-P)

Vincent

[ncohen]

Yo !

The terminology is not understandable:

I just sent you "Combinatorial Designs: Construction and Analysis" from Douglas Stinson which uses (v,k,lambda)-BIBD, TD(k,n) and OA(k,n). I believed that the Handbook of Combinatorial Designs did the same but they actually write BIBD(v,k,lambda). Their purpose was probably to unify notations, given that (v,k,lambda)-BIBD is a pretty common :

​http://www.maths.qmul.ac.uk/~leonard/repeated11.pdf ​http://www.argilo.net/files/bibd.pdf

You will also find other occurrences of this naming in the references of the Handbook.

Othey guys say 2-(v,k,lambda) design.

• MOLS(n,k) but TD(k,n)
• (v,k,lambda)-BIBD but TD(v,k,lambda)

Two remarks :

• MOLS(n,k) does not appear in Sage's code
• It is true that the constructor of MOLS takes first a k then an n as input. It is true that it can lead to mistakes, and perhaps we should change it.
• If you insist on using BIBD(v,k,lambda) it can be done but it has to be a global change as some pages, eg ​http://sagemath.org/doc/reference/combinat/sage/combinat/designs/bibd.html already use this terminology. Same for PBD.

good luck for your future merges... (now you are used to it ;-P)

Nathann