Sage: Ticket #16323: Construction of BIBD with k=5
https://trac.sagemath.org/ticket/16323
<p>
Heeeeeere it is ! At long last. We can build all BIBD with k=5 thanks to this construction :
<a class="ext-link" href="http://www.argilo.net/files/bibd.pdf"><span class="icon"></span>http://www.argilo.net/files/bibd.pdf</a>
</p>
<p>
As usual no design is returned without being checked first, so the code is extremely safe.
</p>
<p>
Nathann
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/16323
Trac 1.1.6ncohenSat, 10 May 2014 20:57:49 GMTstatus, description changed; commit, branch set
https://trac.sagemath.org/ticket/16323#comment:1
https://trac.sagemath.org/ticket/16323#comment:1
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
<li><strong>commit</strong>
set to <em>2ac6aef7804800da10594bb3c3df9bb00c7c552e</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/16323?action=diff&version=1">diff</a>)
</li>
<li><strong>branch</strong>
set to <em>u/ncohen/16323</em>
</li>
</ul>
<p>
Last 10 new commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=5074eee1d802ef44c251252581684bf1dc1dc7d6"><span class="icon"></span>5074eee</a></td><td><code>trac #16272: finer doctest to test the output of transversal_design</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=d81f265637099f93495dafac54e2d354be0d66d5"><span class="icon"></span>d81f265</a></td><td><code>trac #16272: ultimate doctest</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=47798d2d54221c0bd0ce6aa75d1900496a091e2f"><span class="icon"></span>47798d2</a></td><td><code>trac #16272: simplifying the structure of orthogonal_array</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=d34b012758319ebcea5c0a0e17e6481ad5ded481"><span class="icon"></span>d34b012</a></td><td><code>trac #16272: Merged with updated #16227</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=569c4858a95177d1075c756375c28d676f380586"><span class="icon"></span>569c485</a></td><td><code>trac #16279: BIBD from Transversal Designs</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=60e8d35dbd2d0972fab0e306fcecac7e1225dc41"><span class="icon"></span>60e8d35</a></td><td><code>trac #16279: Merged with updated #16272</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=927d325e9f616bce207935130e0065f98e4d4b7f"><span class="icon"></span>927d325</a></td><td><code>trac #16279: Merged with 6.2</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=e1b29bfa50359f01b95ce1c12832935433d19a02"><span class="icon"></span>e1b29bf</a></td><td><code>trac #16279: Fixing the doc</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=e941a54dc3e757b359a54a9fd8f0f49358fad020"><span class="icon"></span>e941a54</a></td><td><code>trac #16279: Merged with updated #16091</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=2ac6aef7804800da10594bb3c3df9bb00c7c552e"><span class="icon"></span>2ac6aef</a></td><td><code>trac #16323: Construction of BIBD with k=5</code>
</td></tr></table>
TicketgitSat, 10 May 2014 21:32:17 GMTcommit changed
https://trac.sagemath.org/ticket/16323#comment:2
https://trac.sagemath.org/ticket/16323#comment:2
<ul>
<li><strong>commit</strong>
changed from <em>2ac6aef7804800da10594bb3c3df9bb00c7c552e</em> to <em>8529434c26b5acb95ead359de0a62c89afefeb16</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=c127a6d52c126483966dbc5faa6436d699a0d4a4"><span class="icon"></span>c127a6d</a></td><td><code>trac #16272: Merged with updated #16231</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=e2749b3db4cd78fc5e9ea8219d4cdf895b283465"><span class="icon"></span>e2749b3</a></td><td><code>trac #16272: Merged with 6.3.beta0</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=4115b7285b56268418304681ed36d08e58cfd3fe"><span class="icon"></span>4115b72</a></td><td><code>trac #16279: Merged with updated #16272</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=8529434c26b5acb95ead359de0a62c89afefeb16"><span class="icon"></span>8529434</a></td><td><code>trac #16323: Merged with #16279</code>
</td></tr></table>
TicketncohenSat, 10 May 2014 21:38:35 GMT
https://trac.sagemath.org/ticket/16323#comment:3
https://trac.sagemath.org/ticket/16323#comment:3
<p>
If anybody wants to really test it :
</p>
<pre class="wiki">for i in range(2,2000):
if designs.BalancedIncompleteBlockDesign(i,5,existence=True):
print i
_ = designs.BalancedIncompleteBlockDesign(i,5)
</pre><p>
Nathann
</p>
TicketleifSun, 11 May 2014 14:29:17 GMTmilestone changed
https://trac.sagemath.org/ticket/16323#comment:4
https://trac.sagemath.org/ticket/16323#comment:4
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.2</em> to <em>sage-6.3</em>
</li>
</ul>
TicketncohenMon, 12 May 2014 09:19:36 GMTdependencies set
https://trac.sagemath.org/ticket/16323#comment:5
https://trac.sagemath.org/ticket/16323#comment:5
<ul>
<li><strong>dependencies</strong>
set to <em>#16279</em>
</li>
</ul>
TicketncohenFri, 16 May 2014 21:14:00 GMTcomponent changed
https://trac.sagemath.org/ticket/16323#comment:6
https://trac.sagemath.org/ticket/16323#comment:6
<ul>
<li><strong>component</strong>
changed from <em>combinatorics</em> to <em>combinatorial designs</em>
</li>
</ul>
TicketgitSat, 17 May 2014 10:23:49 GMTcommit changed
https://trac.sagemath.org/ticket/16323#comment:7
https://trac.sagemath.org/ticket/16323#comment:7
<ul>
<li><strong>commit</strong>
changed from <em>8529434c26b5acb95ead359de0a62c89afefeb16</em> to <em>07a31304b9d48ef6e07f1dd96c1d3185b8fafc95</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=07a31304b9d48ef6e07f1dd96c1d3185b8fafc95"><span class="icon"></span>07a3130</a></td><td><code>trac #16323: Merged with 6.3.beta1</code>
</td></tr></table>
TicketvdelecroixTue, 27 May 2014 17:35:10 GMTstatus changed
https://trac.sagemath.org/ticket/16323#comment:8
https://trac.sagemath.org/ticket/16323#comment:8
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_info</em>
</li>
</ul>
<p>
Hi Nathann,
</p>
<p>
Perhaps not everything for that ticket but I would like to discuss several points.
</p>
<p>
1) <code>BalancedIncompleteBlockDesign</code> is upper case whereas we start to agree on lower case would be for "build me one if you know how to" and CamelCase would be for "build me this precise design". Should I open a ticket for that ?
</p>
<p>
2) BIBD errors are not smart (compared to TD/OA/MOLS)
</p>
<pre class="wiki">sage: designs.BalancedIncompleteBlockDesign(5,6)
...
ValueError: No such design exists !
sage: designs.BalancedIncompleteBlockDesign(1,6)
...
RuntimeError: maximum recursion depth exceeded while calling a Python object
sage: D=designs.BalancedIncompleteBlockDesign(1,5)
...
EmptySetError: No Transversal Design exists when k>=n+2 if n>=2
</pre><p>
3) It would be nice to have <code>BIBD_from_difference_family</code> as a public function as it
may serve other purposes. Moreover, the <code>G(x if some_reason else [x])</code> is
ugly. I know it is because of <code>AdditiveAbelianGroup</code> but it is ugly. There are
ways to avoid that (e.g. use <code>Zmod</code> for cyclic groups instead of
<code>AdditiveAbelianGroup</code>). For that particular point, I do have implementation that smooth everything in u/vdelecroix/16323.
</p>
<p>
4) More generally, there are recursive strategies to build difference family and
difference matrices... it would be nice to have functions
</p>
<pre class="wiki">def difference_family(G, k, l=1, existence=False):
r"""
Return a (G,k,l)-difference family if we know how to...
"""
def difference_matrix(G, k, l=1, existence=False):
r"""
Return a (G,k,l)-difference matrix if we know how to...
""""
</pre><p>
And moreover, such function might be used to simplify the database.
</p>
<p>
5) (not very helpful comment) For v=81, one can write in shorter form
</p>
<pre class="wiki">sage: G = AdditiveAbelianGroup([3]*4)
sage: a,b,c,d = G.gens()
sage: D = [[d, -a+d, -c+d, a-b-d, b+c+d],
....: [c, -b+c, a+b-d, a-b+d, a+b+c],
....: [a+b, -a+c-d, b-c+d, a-b-c-d, -a-b+c+d],
....: [-b-d, a+b+d, a-b+c, -b+c+d, a-b+c-d]]
</pre><p>
Moreover, writing that way it avoids the conversion from tuple to elements of
the group G.
</p>
<p>
Vincent
</p>
TicketncohenTue, 27 May 2014 17:45:03 GMT
https://trac.sagemath.org/ticket/16323#comment:9
https://trac.sagemath.org/ticket/16323#comment:9
<p>
Yooooooooo !!
</p>
<blockquote class="citation">
<p>
Perhaps not everything for that ticket but I would like to discuss several points.
</p>
</blockquote>
<p>
Thanks for reading it, though !
</p>
<blockquote class="citation">
<p>
1) <code>BalancedIncompleteBlockDesign</code> is upper case whereas we start to agree on lower case would be for "build me one if you know how to" and CamelCase would be for "build me this precise design". Should I open a ticket for that ?
</p>
</blockquote>
<p>
Ahahahah... Yes, probably... <code>:-)</code>
</p>
<blockquote class="citation">
<p>
2) BIBD errors are not smart (compared to TD/OA/MOLS)
</p>
<pre class="wiki">sage: designs.BalancedIncompleteBlockDesign(5,6)
...
ValueError: No such design exists !
sage: designs.BalancedIncompleteBlockDesign(1,6)
...
RuntimeError: maximum recursion depth exceeded while calling a Python object
sage: D=designs.BalancedIncompleteBlockDesign(1,5)
...
EmptySetError: No Transversal Design exists when k>=n+2 if n>=2
</pre></blockquote>
<p>
Well, the first one is correct, I am pretty sure I fixed the second somewhere but let's fix it again here, and the third one is really a mistake. I will write a ticket for the last two bugs in a second
</p>
<blockquote class="citation">
<p>
3) It would be nice to have <code>BIBD_from_difference_family</code> as a public function as it
may serve other purposes. Moreover, the <code>G(x if some_reason else [x])</code> is
ugly. I know it is because of <code>AdditiveAbelianGroup</code> but it is ugly.
</p>
</blockquote>
<p>
Yes. But you know, it REALLY is because of <code>AdditiveAbelianGroup</code> ! Anyway now we have real cartesian products, I will use that.
</p>
<blockquote class="citation">
<p>
There are
ways to avoid that (e.g. use <code>Zmod</code> for cyclic groups instead of
<code>AdditiveAbelianGroup</code>). For that particular point, I do have implementation that smooth everything in u/vdelecroix/16323.
</p>
</blockquote>
<p>
Oh... But Zmod is ugly too, because you have to change the way you think of the code.. We can use cartesian products now that we have them !
</p>
<blockquote class="citation">
<p>
4) More generally, there are recursive strategies to build difference family and
difference matrices... it would be nice to have functions
</p>
<pre class="wiki">def difference_family(G, k, l=1, existence=False):
r"""
Return a (G,k,l)-difference family if we know how to...
"""
def difference_matrix(G, k, l=1, existence=False):
r"""
Return a (G,k,l)-difference matrix if we know how to...
""""
</pre><p>
And moreover, such function might be used to simplify the database.
</p>
</blockquote>
<p>
I know nothing about ways to build difference families and differences matrices.
</p>
<p>
Nathann
</p>
TicketncohenTue, 27 May 2014 17:50:16 GMT
https://trac.sagemath.org/ticket/16323#comment:10
https://trac.sagemath.org/ticket/16323#comment:10
<p>
Okay, I just loaded your branch and saw what you did. If you want to expose such a function you must really document it, a bit like the documentation of <code>OA_from_quasi_difference_matrix</code> and <code>OA_from_Vmt</code>. Definine difference matrices, and how the BIBD is produced.
</p>
<p>
I don't know how to do that. That's why I left it as an inlined function.
</p>
<p>
BTW, I think that the name should end with "difference_family", not DF.
</p>
<p>
I will create the bugix ticket in a second.
</p>
<p>
Nathann
</p>
TicketncohenTue, 27 May 2014 18:01:32 GMT
https://trac.sagemath.org/ticket/16323#comment:11
https://trac.sagemath.org/ticket/16323#comment:11
<p>
Okay, actually it seems that the infinite recursion cannot happen when we avoid the stupid cases <code>v=1</code> and <code>k=1</code>. SOoooooooooooo instead of creating a ticket we can fix it here !
</p>
<p>
As I don't know what we will do with your branch and mine I don't write the commit but the fix is easy :
</p>
<pre class="wiki"> """
- if ((binomial(v,2)%binomial(k,2) != 0) or
+ if (v<k or
+ k<2 or
+ (binomial(v,2)%binomial(k,2) != 0) or
(v-1)%(k-1) != 0):
if existence:
</pre><p>
Nathann
</p>
TicketvdelecroixFri, 30 May 2014 09:57:49 GMT
https://trac.sagemath.org/ticket/16323#comment:12
https://trac.sagemath.org/ticket/16323#comment:12
<p>
Hi Nathann,
</p>
<p>
I did the modif in my branch. I also put the case <code>v == k</code> before since <code>[[1]]</code> is a valid BIBD(1,1), isn't it? I also changed some of the <code>ValueError</code> to <code>EmptySetError</code> or <code>NotImplementedError</code>. Now we have
</p>
<pre class="wiki">sage: designs.BalancedIncompleteBlockDesign(5,6)
...
EmptySetError: No such design exists !
sage: designs.BalancedIncompleteBlockDesign(1,6)
...
EmptySetError: No such design exists !
sage: designs.BalancedIncompleteBlockDesign(1,5)
...
EmptySetError: No such design exists !
</pre><p>
For the <code>BIBD_from_difference_family</code> there is now a proper documentation. I also learn that there are some constructions of Wilson, Baratti and Abel-Baratti to build difference families.
</p>
<p>
I still have the Zmod in my branch and I do not know if you want to get rid of them.
</p>
<p>
Vincent
</p>
TicketvdelecroixFri, 30 May 2014 10:24:42 GMT
https://trac.sagemath.org/ticket/16323#comment:13
https://trac.sagemath.org/ticket/16323#comment:13
<p>
Actually, I did a mistake: BIBD(1,k) always exists, just consider an empty set of blocks !!
</p>
TicketncohenSat, 31 May 2014 11:55:15 GMT
https://trac.sagemath.org/ticket/16323#comment:14
https://trac.sagemath.org/ticket/16323#comment:14
<p>
Hello !
</p>
<p>
Did you push the changes ? The branch u/vdelecroix/16323 I just pulled contains the old version of your changes only : the function is still named BIBD_from_DF and contains almost no documentation.
</p>
<p>
Nathann
</p>
TicketvdelecroixSat, 31 May 2014 16:46:26 GMT
https://trac.sagemath.org/ticket/16323#comment:15
https://trac.sagemath.org/ticket/16323#comment:15
<p>
Hi Nathann,
</p>
<p>
My mistake, I did not commit the changes. Now everything is on trac.
</p>
<p>
Vincent
</p>
TicketncohenSat, 31 May 2014 19:07:32 GMT
https://trac.sagemath.org/ticket/16323#comment:16
https://trac.sagemath.org/ticket/16323#comment:16
<p>
Ahahahah very cool ! I did not even know how a difference family was defined. Quite straightforward <code>:-)</code>
</p>
<p>
Okay, I agree with your commits except for three things :
</p>
<ul><li>The new function needs an INPUT section
</li></ul><ul><li>we have several "Design1_from_design2" functions already, so could it be <code>BIBD_from_difference_family</code> like before ?
</li></ul><ul><li>Those two tests are equivalent. Is that on purpose ?
</li></ul><pre class="wiki">+ assert ((v-1)%4 == 0 and (v*(v-1))%20 == 0)
+ assert (v%20 == 5 or v%20 == 1)
</pre><p>
Nathann
</p>
TicketvdelecroixSun, 01 Jun 2014 11:58:31 GMT
https://trac.sagemath.org/ticket/16323#comment:17
https://trac.sagemath.org/ticket/16323#comment:17
<p>
Hi Nathann,
</p>
<p>
I did the correction. Furthermore, there was a typo in the main BIBD (a <code>n</code> was used instead of a <code>v</code>).
</p>
<p>
Now that I read more carefully the code:
</p>
<ul><li>why the construction using PBD can not be used from the main BIBD function? In particular, considering organization, I would like to see the functions <code>BIBD_from_PBD</code>, <code>_check_PBD</code>, <code>_relabel_BIBD</code>, <code>PBD_4_5_8_9_12</code>, <code>_PBD_4_5_8_9_12_closure</code>, <code>PBD_from_TD</code> much higher in the file, i.e. neither in the part "(v,4,1)-BIBD" nor in the part "(v,5,1)-BIBD".
</li><li>More generally, the functions <code>steiner_triple_system</code>, <code>v_4_1_BIBD</code> and <code>v_5_1_BIBD</code> currently follow various proofs. But we only care about constructing the BIBD and not checking the proofs, doesn't we? We certainly "check" the proof in the doctests but wouldn't it be possible to write in the main BIBD:
<pre class="wiki">if database.BIBD[v,k]:
...
elif construction1(v,k,existence=True):
...
elif construction2(v,k,existence=True):
...
</pre>and getting rid of <code>steiner_triple_system</code>, <code>v_4_1_BIBD</code> and <code>v_5_1_BIBD</code>? I understand that it would be a dramatical change, so do not answer considering it as a task for that ticket.
</li></ul><p>
Vincent
</p>
TicketncohenSun, 01 Jun 2014 14:58:15 GMTcommit, branch changed
https://trac.sagemath.org/ticket/16323#comment:18
https://trac.sagemath.org/ticket/16323#comment:18
<ul>
<li><strong>commit</strong>
changed from <em>07a31304b9d48ef6e07f1dd96c1d3185b8fafc95</em> to <em>8eac6d069e162aed9d4fc1ae3f654d0b446573da</em>
</li>
<li><strong>branch</strong>
changed from <em>u/ncohen/16323</em> to <em>u/vdelecroix/16323</em>
</li>
</ul>
<p>
Hello !
</p>
<blockquote class="citation">
<p>
Now that I read more carefully the code:
</p>
<ul><li>why the construction using PBD can not be used from the main BIBD function?
</li></ul></blockquote>
<p>
You mean that if we had a constructor for PBD we could call it from the BIBD constructor using BIBD_from_PBD ? It is true, but we have no PBD constructor at the moment. Besides the two PBD constructors we already have we could add a PBD_from_TD, stuff like that, indeed.
</p>
<blockquote class="citation">
<p>
In particular, considering organization, I would like to see the functions <code>BIBD_from_PBD</code>, <code>_check_PBD</code>, <code>_relabel_BIBD</code>, <code>PBD_4_5_8_9_12</code>, <code>_PBD_4_5_8_9_12_closure</code>, <code>PBD_from_TD</code> much higher in the file, i.e. neither in the part "(v,4,1)-BIBD" nor in the part "(v,5,1)-BIBD".
</p>
</blockquote>
<p>
Move stuff around if you want. As far as I am concerned, it is totally pointless. This being said, some of those functions are together in the code because I implemented the, following the same reference, so if you move them apart please leave them linked together somehow.
</p>
<blockquote class="citation">
<ul><li>More generally, the functions <code>steiner_triple_system</code>, <code>v_4_1_BIBD</code> and <code>v_5_1_BIBD</code> currently follow various proofs. But we only care about constructing the BIBD and not checking the proofs, doesn't we? We certainly "check" the proof in the doctests but wouldn't it be possible to write in the main BIBD:
<pre class="wiki">if database.BIBD[v,k]:
...
elif construction1(v,k,existence=True):
...
elif construction2(v,k,existence=True):
...
</pre></li></ul></blockquote>
<p>
Hmmmmm... You are right that it would be equivalent, you are right that we have no automatic way to chec that the proof is right, but as it is implemented you can deduce, from looking at the code, that this is the intent and so that it is what the function does. Also, these functions have a documentation and comments which are related to the papers I followed to implement them, and this would be much harder to see if you poured them all in the main constructors.
</p>
<p>
Another thing : sometimes the v_5_1_BIBD construction (for instance) needs a smaller BIBD to produce a larger one, but it does not call the main BIBD constructor because we know from the proof that this smaller bibd can be obtained by some specific construction. So well, it it implemented directly.
</p>
<p>
So well.... I rather like to have these functions which somehow claim that "these cases are all dealt with", which would not be straightforward to see if all constructors were included in the main function. And if something which those constructions require is of more general use we can of course expose it inside of the main constructor.
</p>
<p>
The original code for BIBD with k=5 was actually much larger... <a class="closed ticket" href="https://trac.sagemath.org/ticket/16279" title="enhancement: BIBD from Transversal Designs (closed: fixed)">#16279</a> is one of these parts.
Nathann
</p>
<hr />
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=0610c7d2fe143405b38b0ee6aa63373bdf193e5e"><span class="icon"></span>0610c7d</a></td><td><code>trac #16323: external BIBD_from_DF and use Zmod</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=daae63e125af9a05b9f3959ab4bca71655354083"><span class="icon"></span>daae63e</a></td><td><code>trac #16323: DF -> difference_family, change errors and more doc</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=8eac6d069e162aed9d4fc1ae3f654d0b446573da"><span class="icon"></span>8eac6d0</a></td><td><code>trac #16323: several fix + doc</code>
</td></tr></table>
TicketvdelecroixSun, 01 Jun 2014 21:39:59 GMTstatus changed; reviewer set
https://trac.sagemath.org/ticket/16323#comment:19
https://trac.sagemath.org/ticket/16323#comment:19
<ul>
<li><strong>status</strong>
changed from <em>needs_info</em> to <em>positive_review</em>
</li>
<li><strong>reviewer</strong>
set to <em>Vincent Delecroix</em>
</li>
</ul>
<p>
Hello,
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/16323#comment:18" title="Comment 18">ncohen</a>:
</p>
<blockquote class="citation">
<p>
Hello !
</p>
<blockquote class="citation">
<p>
Now that I read more carefully the code:
</p>
<ul><li>why the construction using PBD can not be used from the main BIBD function?
</li></ul></blockquote>
<p>
You mean that if we had a constructor for PBD we could call it from the BIBD constructor using BIBD_from_PBD ? It is true, but we have no PBD constructor at the moment. Besides the two PBD constructors we already have we could add a PBD_from_TD, stuff like that, indeed.
</p>
</blockquote>
<p>
I bet that there are some PBD constructions in the Handbook... We should keep in mind to reuse this code at some point.
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
In particular, considering organization, I would like to see the functions <code>BIBD_from_PBD</code>, <code>_check_PBD</code>, <code>_relabel_BIBD</code>, <code>PBD_4_5_8_9_12</code>, <code>_PBD_4_5_8_9_12_closure</code>, <code>PBD_from_TD</code> much higher in the file, i.e. neither in the part "(v,4,1)-BIBD" nor in the part "(v,5,1)-BIBD".
</p>
</blockquote>
<p>
Move stuff around if you want. As far as I am concerned, it is totally pointless. This being said, some of those functions are together in the code because I implemented them, following the same reference, so if you move them apart please leave them linked together somehow.
</p>
</blockquote>
<p>
I do not care too much. But, when I opened the file the first time it was difficult to found the logic.
</p>
<blockquote class="citation">
<p>
[...]
And if something which those constructions require is of more general use we can of course expose it inside of the main constructor.
</p>
</blockquote>
<p>
Indeed, this was my main question. (I had a look at various paper about difference families, and there are a lot about k=3,4,5, very few about k=6 and almost none about k>=7; excepted existence result for very large v).
</p>
<p>
I found the work done in the branch is enough for the ticket so I set to positive review.
</p>
<p>
Vincent
</p>
TicketncohenSun, 01 Jun 2014 21:50:46 GMT
https://trac.sagemath.org/ticket/16323#comment:20
https://trac.sagemath.org/ticket/16323#comment:20
<p>
Yo !!
</p>
<p>
Thanks for the review !
</p>
<blockquote class="citation">
<p>
I bet that there are some PBD constructions in the Handbook... We should keep in mind to reuse this code at some point.
</p>
</blockquote>
<p>
Indeed, but my fear with PBD construction is that it may become harder to detect if we can build one. I mean.. If you have a <code>(100,[4,6,8])-PBD</code> and a <code>(6,[3])-PBD</code> then you have also a <code>(100,[3,4,8])-PBD</code>, stuff like that. You can really mix a lot of different things there, soooo... Well. It may be tricky. We will do it, but it will be tricky to do it well.
</p>
<blockquote class="citation">
<p>
I do not care too much. But, when I opened the file the first time it was difficult to found the logic.
</p>
</blockquote>
<p>
AHahah. ALl this is there for "historical reasons" I fear. Implemented one after the other. I expect that it will be cleaned several times in the future.
</p>
<blockquote class="citation">
<p>
Indeed, this was my main question. (I had a look at various paper about difference families, and there are a lot about k=3,4,5, very few about k=6 and almost none about k>=7; excepted existence result for very large v).
</p>
</blockquote>
<p>
Indeed, but Julian R. Abel told me that some recursive construction may be by itself sufficient to generate all (v,6,1)-BIBD with v>1000. Looks like when you have a lot of recursive construction you can do almost everything, and that some base cases will be the only missing things afterwards.
</p>
<p>
Ahahaah.
</p>
<p>
The point is that it is all a lot of work, and all an interesting work too. And I would like to add it someday, but for the moment I would like to finish implementing all the OA/TD/MOLS related code. I have some new constructions to add but I did not write the branch yet for it would depend on other tickets, and I am pretty sure that the main functions I need will be rewritten and changed during the reviews, so I don't dare write this yet as it will mean a lot of rebase. But when the OA/TD/MOLS stuff will be done, both PBD and BIBD with larger blocks will be on the table.
</p>
<blockquote class="citation">
<p>
I found the work done in the branch is enough for the ticket so I set to positive review.
</p>
</blockquote>
<p>
Thaaaaaaaaaaaaaanks ! I will write to the author of the pdf file tomorrow <code>:-)</code>
</p>
<p>
Nathann
</p>
TicketvbraunMon, 02 Jun 2014 15:56:24 GMTstatus, branch changed; resolution set
https://trac.sagemath.org/ticket/16323#comment:21
https://trac.sagemath.org/ticket/16323#comment:21
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
<li><strong>branch</strong>
changed from <em>u/vdelecroix/16323</em> to <em>8eac6d069e162aed9d4fc1ae3f654d0b446573da</em>
</li>
</ul>
Ticket