Sage: Ticket #16391: Helper functions for OA constructions
https://trac.sagemath.org/ticket/16391
<p>
This adds two helper functions that are heavily used by all the OA construction routines that I currently implement. Aaaaaaand which will be in Sage asap !
</p>
<p>
Nathann
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/16391
Trac 1.1.6ncohenFri, 23 May 2014 15:35:50 GMTstatus, cc changed; commit, branch set
https://trac.sagemath.org/ticket/16391#comment:1
https://trac.sagemath.org/ticket/16391#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>395458fdb6487289f5add7702c7c6fe66018ad96</em>
</li>
<li><strong>cc</strong>
<em>vdelecroix</em> <em>knsam</em> <em>brett</em> added; <em>vdele</em> removed
</li>
<li><strong>branch</strong>
set to <em>u/ncohen/16391</em>
</li>
</ul>
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=90a72bd39d74c24cb548e5b7dc5995c67ac386f8"><span class="icon"></span>90a72bd</a></td><td><code>trac #16370: OA(k,n) strongly regular graphs</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=395458fdb6487289f5add7702c7c6fe66018ad96"><span class="icon"></span>395458f</a></td><td><code>trac #16391: Helper functions for OA constructions</code>
</td></tr></table>
TicketgitMon, 26 May 2014 12:58:40 GMTcommit changed
https://trac.sagemath.org/ticket/16391#comment:2
https://trac.sagemath.org/ticket/16391#comment:2
<ul>
<li><strong>commit</strong>
changed from <em>395458fdb6487289f5add7702c7c6fe66018ad96</em> to <em>f86d187a1fdd25bb662663de314fd1528e675fc0</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=0ed318ef025a88b2ef5f69891b03fb60b725c7a7"><span class="icon"></span>0ed318e</a></td><td><code>trac #16391: Merged with 6.3.beta2</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=f86d187a1fdd25bb662663de314fd1528e675fc0"><span class="icon"></span>f86d187</a></td><td><code>trac #16391: small improvement</code>
</td></tr></table>
TicketncohenThu, 29 May 2014 17:50:42 GMT
https://trac.sagemath.org/ticket/16391#comment:3
https://trac.sagemath.org/ticket/16391#comment:3
<p>
Small update to find an "independent set of order x" with a Linear Program.
</p>
<ul><li>Calling <code>Graph.independent_set()</code> would work but the function could take forever trying to decide if there exists an independent set of order 14 or 15 when we only need 2.
</li></ul><ul><li>Calling <code>subgraph_search</code> as was done just before this commit is a bad algorithm when there are no solutions. A VERY bad algorithm <code>:-P</code>
</li></ul><p>
Nathann
</p>
TicketgitThu, 29 May 2014 17:55:30 GMTcommit changed
https://trac.sagemath.org/ticket/16391#comment:4
https://trac.sagemath.org/ticket/16391#comment:4
<ul>
<li><strong>commit</strong>
changed from <em>f86d187a1fdd25bb662663de314fd1528e675fc0</em> to <em>d954b936c11f31d79b5dca0d6b8da579afb53d5f</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=d954b936c11f31d79b5dca0d6b8da579afb53d5f"><span class="icon"></span>d954b93</a></td><td><code>trac #16391: Independent Set problem with a LP</code>
</td></tr></table>
TicketgitMon, 02 Jun 2014 10:50:07 GMTcommit changed
https://trac.sagemath.org/ticket/16391#comment:5
https://trac.sagemath.org/ticket/16391#comment:5
<ul>
<li><strong>commit</strong>
changed from <em>d954b936c11f31d79b5dca0d6b8da579afb53d5f</em> to <em>2090875de8a5d9a0301a85fc35e0e60a068de1ab</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=2090875de8a5d9a0301a85fc35e0e60a068de1ab"><span class="icon"></span>2090875</a></td><td><code>trac #16391: Small improvement</code>
</td></tr></table>
TicketvdelecroixTue, 03 Jun 2014 11:19:24 GMT
https://trac.sagemath.org/ticket/16391#comment:6
https://trac.sagemath.org/ticket/16391#comment:6
<p>
Hi Nathann,
</p>
<p>
I switch to this one from <a class="closed ticket" href="https://trac.sagemath.org/ticket/16361" title="enhancement: OA(7,66), OA(7,68), OA(8,69), OA(7,74) and OA(8,76) (closed: fixed)">#16361</a> because of the comment I wrote there. But in the function <code>OA_with_holes</code> implemented in the branch associated to that ticket, you do strictly the same thing. You rely heavily on the output of <code>designs.orthogonal_array(k,n)</code> whose specifications are : "Returns <strong>an</strong> orthogonal array with parameters (k,n)". It is neither intended to be constant over time (and you do not want to impose that) and it is not optimized with respect to any property. One reason is that we want to shortcut as possible the recursive constructions which are time consuming. If someone comes with a nice one parameter family of <code>OA(k, k^2 + 3*k + 19)</code> we would use that first whatever it breaks elsewhere.
</p>
<p>
You can not reasonably force the implementation of <code>designs.orthogonal_array</code> to output something optimal with respect to the property you are interested in today. It might really be that tomorrow, you would prefer to have a <code>designs.orthogonal_array</code> with very few multiplicity of <code>TD(k,1)</code> in it.
</p>
<p>
Right now, we have several constructions of OA with the same parameters (for example, several Wilson construction might be available). The multiplicity of <code>TD(k,1)</code> you obtain must strongly depend on the way you did your construction and <strong>we do not want</strong> that <code>designs.orthogonal_array</code> takes this strategy.
</p>
<p>
Vincent
</p>
TicketvdelecroixTue, 03 Jun 2014 11:19:37 GMTstatus changed
https://trac.sagemath.org/ticket/16391#comment:7
https://trac.sagemath.org/ticket/16391#comment:7
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_info</em>
</li>
</ul>
TicketncohenTue, 03 Jun 2014 11:29:48 GMT
https://trac.sagemath.org/ticket/16391#comment:8
https://trac.sagemath.org/ticket/16391#comment:8
<p>
Yo Vincent !
</p>
<p>
I cannot claim that <code>OA_with_holes</code> will always output "optimal results", and I never did.
</p>
<p>
I need those designs for constructions of OA that we cannot build at the moment, and I have no other way to produce them. What is the problem with seeing this function as
</p>
<p>
1) When x<=3 we know that it exists
</p>
<p>
2) When there is a <code>OA(k+1,n)</code> we know that it exists
</p>
<p>
3) If everything else fails, see if you are lucky
</p>
<p>
And you want me to remove feature 3), even though it does return helpful things. I never claimed that the results would not change, and what I know for sure is that the results WILL improve as we add new OA. It is true, I cannot prove that eventually feature 3) will never become less powerful.
</p>
<p>
And so what ? Do I throw all my useful code away because of that ? I really have no other way to generate these designs.
</p>
<blockquote class="citation">
<p>
The multiplicity of TD(k,1) you obtain must strongly depend on the way you did your construction
</p>
</blockquote>
<p>
We have no proof of that. And I did not claim the contrary, but we have no proof of that. For instance the proof that it always exists when x<=3 is the proof that any OA contains an independent set of size 3, which means that the result will always hold in this case regardless of which OA is returned.
</p>
<p>
Nathann
</p>
TicketncohenTue, 03 Jun 2014 11:37:31 GMTstatus changed
https://trac.sagemath.org/ticket/16391#comment:9
https://trac.sagemath.org/ticket/16391#comment:9
<ul>
<li><strong>status</strong>
changed from <em>needs_info</em> to <em>needs_review</em>
</li>
</ul>
<p>
(by the way, the "independent set" problem makes it independent from the actual labelling of the OA. Even though, of course, it says nothing about non-isomorphic OA)
</p>
TicketvdelecroixTue, 03 Jun 2014 11:41:38 GMT
https://trac.sagemath.org/ticket/16391#comment:10
https://trac.sagemath.org/ticket/16391#comment:10
<p>
Hi Nathann,
</p>
<p>
Thanks for your clarification.
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/16391#comment:8" title="Comment 8">ncohen</a>:
</p>
<blockquote class="citation">
<p>
I cannot claim that <code>OA_with_holes</code> will always output "optimal results", and I never did.
</p>
<p>
I need those designs for constructions of OA that we cannot build at the moment, and I have no other way to produce them. What is the problem with seeing this function as
</p>
<p>
1) When k<=3 we know that it exists
2) When there is a <code>OA(k+1,n)</code> we know that it exists
3) If everything else fails, see if you are lucky
</p>
<p>
And you want me to remove feature 3), even though it does return helpful things. I never claimed that the results would not change, and what I know for sure is that the results WILL improve as we add new OA. It is true, I cannot prove that eventually feature 3) will never become less powerful.
</p>
</blockquote>
<p>
I do not want you to remove it but I do not want to see code or doctests that depend on the lucky case 3). Which implies that you should not use <code>k > 3</code> anywhere. In the current ticket this function is not used at all, so... Where this code is merged with <a class="closed ticket" href="https://trac.sagemath.org/ticket/16391" title="enhancement: Helper functions for OA constructions (closed: fixed)">#16391</a>?
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
The multiplicity of TD(k,1) you obtain must strongly depend on the way you did your construction
</p>
</blockquote>
<p>
We have no proof of that. And I did not claim the contrary, but we have no proof of that. For instance the proof that it always exists when k<=3 is the proof that any OA contains an independent set of size 3, which means that the result will always hold in this case regardless of which OA is returned.
</p>
</blockquote>
<p>
Is there a way to find the largest set of disjoint blocks?
</p>
<p>
Vincent
</p>
TicketncohenTue, 03 Jun 2014 11:57:10 GMT
https://trac.sagemath.org/ticket/16391#comment:11
https://trac.sagemath.org/ticket/16391#comment:11
<p>
Yo !
</p>
<blockquote class="citation">
<p>
I do not want you to remove it but I do not want to see code or doctests that depend on the lucky case 3). Which implies that you should not use <code>k > 3</code> anywhere.
</p>
</blockquote>
<p>
....
</p>
<p>
So I can implement it but I am forbidden to use it ?...
</p>
<p>
Look at what you are doing : you are telling me that it is very bad that in the future some OA with holes may not exist anymore, for the very same reason that in the future some OA with holes may become available.
</p>
<p>
Because we may change constructions, and because if a change can occur in one direction it can occur in the other direction too.
</p>
<p>
So the problem is that the "performance may change" in the future, and in both directions. And more importanty that a doctest may be broken because somebody ADDS a construction of an OA we were already able to build, which should not have any effect...
</p>
<p>
Look man, I have no way around that. I am quite ready to accept that adding a construction may destroy another whose existence could not be proved formally, because this thing is useful for a lot of stuff.
</p>
<p>
And that, again, I have no way around.
</p>
<p>
And that it only returns true results anyway.
</p>
<p>
It is a heuristic. It returns true things, but it may not always find them.
</p>
<blockquote class="citation">
<p>
In the current ticket this function is not used at all, so... Where this code is merged with <a class="closed ticket" href="https://trac.sagemath.org/ticket/16391" title="enhancement: Helper functions for OA constructions (closed: fixed)">#16391</a>?
</p>
</blockquote>
<p>
<a class="closed ticket" href="https://trac.sagemath.org/ticket/16391" title="enhancement: Helper functions for OA constructions (closed: fixed)">#16391</a> is the ticket on which we are talking, so I guess you talk about <a class="closed ticket" href="https://trac.sagemath.org/ticket/16361" title="enhancement: OA(7,66), OA(7,68), OA(8,69), OA(7,74) and OA(8,76) (closed: fixed)">#16361</a>. And the ticket which makes <a class="closed ticket" href="https://trac.sagemath.org/ticket/16361" title="enhancement: OA(7,66), OA(7,68), OA(8,69), OA(7,74) and OA(8,76) (closed: fixed)">#16361</a> use this helper function is Wilson's construction <a class="closed ticket" href="https://trac.sagemath.org/ticket/16347" title="enhancement: Wilson's constructions of OA with 2 truncated groups (closed: fixed)">#16347</a>. I gave you the updated version of that code in my last comment on <a class="closed ticket" href="https://trac.sagemath.org/ticket/16361" title="enhancement: OA(7,66), OA(7,68), OA(8,69), OA(7,74) and OA(8,76) (closed: fixed)">#16361</a>.
</p>
<blockquote class="citation">
<p>
Is there a way to find the largest set of disjoint blocks?
</p>
</blockquote>
<p>
Well, this is precisely what this function does. It solves a maximum independent set problem on the intersection graph. On a specific OA of course.
</p>
<p>
If you want to know if theory knows what the largest set of disjoint blocks for any k,n I expect that the answer is no. If there exists an OA(k+1,n) there there exists an OA(k,n)-n.OA(k,1) but it is apparently not an equivalence.
</p>
<p>
Nathann
</p>
TicketgitThu, 05 Jun 2014 10:48:36 GMTcommit changed
https://trac.sagemath.org/ticket/16391#comment:12
https://trac.sagemath.org/ticket/16391#comment:12
<ul>
<li><strong>commit</strong>
changed from <em>2090875de8a5d9a0301a85fc35e0e60a068de1ab</em> to <em>90f828fb2904fc5083baa8b45af97d6dc7740f54</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=74c30a6810511eaf5f613713e4f1f88f44fee33d"><span class="icon"></span>74c30a6</a></td><td><code>trac #16370: Merged with 6.3.beta2</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=e3c1c2180178c94d883db945dc33f2b457330cbc"><span class="icon"></span>e3c1c21</a></td><td><code>trac #16370: Parameters of the SRG in the doc</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=e469bb5b23d7862b48082f1cba9fd946dd7dc406"><span class="icon"></span>e469bb5</a></td><td><code>trac #16370: Warnings in the constructor</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=1a3255c469bfe3c7f01a56e5c7ec3fbde56f047d"><span class="icon"></span>1a3255c</a></td><td><code>trac #16370: Merged with 6.3.beta3</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=7b73bc55865f7c7bd454dd047dc38f0ed2ff58be"><span class="icon"></span>7b73bc5</a></td><td><code>trac #16370: Reviewer's comments</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=d1e272f81fbd464af0f46199faa3b3fb1eda2376"><span class="icon"></span>d1e272f</a></td><td><code>trac #16370: Reviewer's comments 2</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=bdae80af1b51e30d9bd823a8c9aba7af41325d3d"><span class="icon"></span>bdae80a</a></td><td><code>trac #16370: more docs</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=406aaef2ae9702296cc551c1649eb8d808c5d41d"><span class="icon"></span>406aaef</a></td><td><code>trac #16391: Merged with updated #16370</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=90f828fb2904fc5083baa8b45af97d6dc7740f54"><span class="icon"></span>90f828f</a></td><td><code>trac #16391: use OrthogonalArrayBlockGraph instead of OrthogonalArrayGraph</code>
</td></tr></table>
TicketvdelecroixFri, 06 Jun 2014 19:05:20 GMTstatus changed
https://trac.sagemath.org/ticket/16391#comment:13
https://trac.sagemath.org/ticket/16391#comment:13
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_info</em>
</li>
</ul>
<p>
Hi,
</p>
<p>
1) What you called OA with holes are "incomplete orthogonal array" in the Handbook (as well as their sisters "incomplete transversal design" and "incomplete set of MOLS"). See p 193-194. And the one you are interested in, the "OA(k,n) - x.OA(k,1)", are also denoted "OA(k,n; 1, ..., 1)". Am I right? If this is true, I would rather write a function <code>incomplete_orthogonal_array(k,n,holes)</code> where holes is a tuple of integers to fit with the standard names and notations. I also saw some general results in the Handbook (Theorems 4.16 and 4.17) about one hole and k=4,5... and a beautiful table of IMOLS.
</p>
<p>
2) From the function you wrote, it is very easy to
</p>
<ul><li>allow <code>x</code> as None, in which case the function tries to optimize the number of holes
</li><li>have an optional argument <code>OA</code> such that, if it is provided, the function looks for holes inside this orthogonal array.
</li></ul><p>
I did the change myself but the function looks a bit uglier so I am not sure what to do. I would like to have those two functions to study the number of holes depending on the OA. But on the other hand, I tried with the OA(4,10) that we have but it took lifetime to obtain the answer 9.
</p>
<p>
A perhaps cleaner way to do things is to have two functions that would looks like
</p>
<ul><li><code>incomplete_orthogonal_array(k,n,holes)</code> (this function would be available from the global namespace)
</li><li><code>look_for_holes_in_my_OA(OA,k,n,holes)</code>
</li></ul><p>
What do you think?
</p>
<p>
Vincent
</p>
TicketncohenSat, 07 Jun 2014 08:47:38 GMTstatus changed
https://trac.sagemath.org/ticket/16391#comment:14
https://trac.sagemath.org/ticket/16391#comment:14
<ul>
<li><strong>status</strong>
changed from <em>needs_info</em> to <em>needs_review</em>
</li>
</ul>
<p>
Yo !
</p>
<blockquote class="citation">
<p>
1) What you called OA with holes are "incomplete orthogonal array" in the Handbook
</p>
</blockquote>
<p>
I see I see. Somehow I think that I was mixing together "incomplete TD" and "truncated TD". For me an "incomplete TD" could be an OA truncated in any way, though it seems that it actually is a "nicely truncated TD", i.e. that the missing stuff can potentially be filled with others TD.
</p>
<p>
Note that I have no clue how I could compute a decomposition of a TD with holes of size > 1. No idea.
</p>
<blockquote class="citation">
<p>
(as well as their sisters "incomplete transversal design" and "incomplete set of MOLS"). See p 193-194. And the one you are interested in, the "OA(k,n) - x.OA(k,1)", are also denoted "OA(k,n; 1, ..., 1)". Am I right? If this is true, I would rather write a function <code>incomplete_orthogonal_array(k,n,holes)</code> where holes is a tuple of integers to fit with the standard names and notations. I also saw some general results in the Handbook (Theorems 4.16 and 4.17) about one hole and k=4,5... and a beautiful table of IMOLS.
</p>
</blockquote>
<p>
Okay, then we can implement it like that : <code>incomplete_transversal_design(k,n,tuple_of_hole_sizes,OA=None)</code>.
</p>
<p>
The function would return an exception whenever there is an element in tuple_of_hole_sizes which is not equal to 1, and if <code>OA</code> is defined then it is the OA that will be used to compute the holes ?
</p>
<blockquote class="citation">
<p>
2) From the function you wrote, it is very easy to
</p>
<ul><li>allow <code>x</code> as None, in which case the function tries to optimize the number of holes
</li></ul></blockquote>
<p>
Holes of size 1.
</p>
<blockquote class="citation">
<ul><li>have an optional argument <code>OA</code> such that, if it is provided, the function looks for holes inside this orthogonal array.
</li></ul></blockquote>
<p>
Yepyep.
</p>
<blockquote class="citation">
<p>
I did the change myself but the function looks a bit uglier so I am not sure what to do. I would like to have those two functions to study the number of holes depending on the OA. But on the other hand, I tried with the OA(4,10) that we have but it took lifetime to obtain the answer 9.
</p>
</blockquote>
<p>
Yep. I tried different things an really this small LP appears to be the best choice. If we make the optimization available then we will have to call <code>Graph.independent_set</code>.
</p>
<blockquote class="citation">
<p>
A perhaps cleaner way to do things is to have two functions that would looks like
</p>
<ul><li><code>incomplete_orthogonal_array(k,n,holes)</code> (this function would be available from the global namespace)
</li></ul></blockquote>
<p>
Yepyep, this could be <code>designs.incomplete_orthogonal_array</code>
</p>
<blockquote class="citation">
<ul><li><code>look_for_holes_in_my_OA(OA,k,n,holes)</code>
</li></ul></blockquote>
<p>
I would not know where to write that. It does not belong to <code>designs.<tab></code>. We could write it somewhere in the <code>orthogonal_array</code> file, to let it be exposed later when all this will have become a class.
</p>
<blockquote class="citation">
<p>
What do you think?
</p>
</blockquote>
<p>
What do you think ? Answer my questions above and I will write the code. And rebase what needs to be, above.
</p>
<p>
Nathann
</p>
TicketvdelecroixSat, 07 Jun 2014 09:12:52 GMT
https://trac.sagemath.org/ticket/16391#comment:15
https://trac.sagemath.org/ticket/16391#comment:15
<p>
Hello,
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/16391#comment:14" title="Comment 14">ncohen</a>:
</p>
<blockquote class="citation">
<p>
Yo !
</p>
<blockquote class="citation">
<p>
1) What you called OA with holes are "incomplete orthogonal array" in the Handbook
</p>
</blockquote>
<p>
I see I see. Somehow I think that I was mixing together "incomplete TD" and "truncated TD". For me an "incomplete TD" could be an OA truncated in any way, though it seems that it actually is a "nicely truncated TD", i.e. that the missing stuff can potentially be filled with others TD.
</p>
<p>
Note that I have no clue how I could compute a decomposition of a TD with holes of size > 1. No idea.
</p>
</blockquote>
<p>
For now, we do not care. But there are examples and references in the Handbook.
</p>
<blockquote class="citation">
<p>
Okay, then we can implement it like that : <code>incomplete_transversal_design(k,n,tuple_of_hole_sizes,OA=None)</code>.
</p>
<p>
The function would return an exception whenever there is an element in tuple_of_hole_sizes which is not equal to 1, and if <code>OA</code> is defined then it is the OA that will be used to compute the holes ?
</p>
</blockquote>
<p>
Perfect. It is a bit dummy but it is more terminology compliant and lets the door open.
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
2) From the function you wrote, it is very easy to
</p>
<ul><li>allow <code>x</code> as None, in which case the function tries to optimize the number of holes
</li></ul></blockquote>
<p>
Holes of size 1.
</p>
</blockquote>
<p>
yes. my mistake.
</p>
<blockquote class="citation">
<blockquote class="citation">
<ul><li>have an optional argument <code>OA</code> such that, if it is provided, the function looks for holes inside this orthogonal array.
</li></ul></blockquote>
<p>
Yepyep.
</p>
<blockquote class="citation">
<p>
I did the change myself but the function looks a bit uglier so I am not sure what to do. I would like to have those two functions to study the number of holes depending on the OA. But on the other hand, I tried with the OA(4,10) that we have but it took lifetime to obtain the answer 9.
</p>
</blockquote>
<p>
Yep. I tried different things and really this small LP appears to be the best choice. If we make the optimization available then we will have to call <code>Graph.independent_set</code>.
</p>
</blockquote>
<p>
With the OA(4,10) that has 100 blocks, what would be the best strategy? It took me more than a minute with the MILP (using either glpk or cbc).
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
A perhaps cleaner way to do things is to have two functions that would looks like
</p>
<ul><li><code>incomplete_orthogonal_array(k,n,holes)</code> (this function would be available from the global namespace)
</li></ul></blockquote>
<p>
Yepyep, this could be <code>designs.incomplete_orthogonal_array</code>
</p>
</blockquote>
<p>
Great!
</p>
<blockquote class="citation">
<blockquote class="citation">
<ul><li><code>look_for_holes_in_my_OA(OA,k,n,holes)</code>
</li></ul></blockquote>
<p>
I would not know where to write that. It does not belong to <code>designs.<tab></code>. We could write it somewhere in the <code>orthogonal_array</code> file, to let it be exposed later when all this will have become a class.
</p>
</blockquote>
<p>
This is what I meant, not a public function. You can call it whatever you want. But I really would like that it accepts an optional OA as argument in the very same way <code>graphs.OrthogonalArrayBlockGraph</code> does. Perhaps a more appropriate name would be, <code>OA_find_disjoint_block</code>?
</p>
<p>
Vincent
</p>
TicketvdelecroixSat, 07 Jun 2014 09:14:48 GMT
https://trac.sagemath.org/ticket/16391#comment:16
https://trac.sagemath.org/ticket/16391#comment:16
<p>
Sorry, I meant
</p>
<ul><li><code>designs.incomplete_transversal_design(k,n,holes)</code> <--- no OA argument here
</li><li>a private <code>OA_find_disjoint_blocks(k,n,x,OA=None)</code>
</li></ul><p>
And of course you can use caching on the first one.
</p>
<p>
Vincent
</p>
TicketncohenSat, 07 Jun 2014 13:48:09 GMT
https://trac.sagemath.org/ticket/16391#comment:17
https://trac.sagemath.org/ticket/16391#comment:17
<p>
Hello !
</p>
<p>
Here is the updated code.
</p>
<p>
As it is the feature "give me the maximum number of disjoint blocks" is not available, but it can be easily added later. This being said if we do that perhaps the best algorithm to use is not the LP solver but rather <code>graphs.OrthogonalArrayBlockGraph(k,n).independent_set(algorithm=something)</code>. And it seems that the best something, even though it is an optional package at the moment, may be MCQD <a class="closed ticket" href="https://trac.sagemath.org/ticket/16083" title="enhancement: MCQD to compute max cliques (closed: fixed)">#16083</a>.
</p>
<p>
Ready for review again !
</p>
<p>
Nathann
</p>
TicketgitSat, 07 Jun 2014 13:49:09 GMTcommit changed
https://trac.sagemath.org/ticket/16391#comment:18
https://trac.sagemath.org/ticket/16391#comment:18
<ul>
<li><strong>commit</strong>
changed from <em>90f828fb2904fc5083baa8b45af97d6dc7740f54</em> to <em>6e3c6856da596aa0b05c82c2f3cbcf48dbd3812a</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=6e3c6856da596aa0b05c82c2f3cbcf48dbd3812a"><span class="icon"></span>6e3c685</a></td><td><code>trac #16391: reviewer's comments</code>
</td></tr></table>
TicketvdelecroixSat, 07 Jun 2014 16:03:22 GMT
https://trac.sagemath.org/ticket/16391#comment:19
https://trac.sagemath.org/ticket/16391#comment:19
<p>
Hi,
</p>
<p>
Great. But you did not remove the holes! An <code>IOA(k,n; h_1, ..., h_s)</code> must have <code>n^2 - sum(h_i^2)</code> blocks. Would that be hard to adapt?
</p>
<p>
I wrote a function <code>is_incomplete_orthogonal_array</code> but I do not want interferences with <a class="closed ticket" href="https://trac.sagemath.org/ticket/16295" title="enhancement: Faster is_orthogonal_array (closed: fixed)">#16295</a>. I will attach the file to the ticket.
</p>
<p>
Vincent
</p>
TicketvdelecroixSat, 07 Jun 2014 16:03:58 GMTattachment set
https://trac.sagemath.org/ticket/16391
https://trac.sagemath.org/ticket/16391
<ul>
<li><strong>attachment</strong>
set to <em>is_incomplete_orthogonal_array.py</em>
</li>
</ul>
<p>
an implementation of is_incomplete_orthogonal_array
</p>
TicketvdelecroixSat, 07 Jun 2014 16:04:18 GMTstatus changed
https://trac.sagemath.org/ticket/16391#comment:20
https://trac.sagemath.org/ticket/16391#comment:20
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_info</em>
</li>
</ul>
TicketgitSat, 07 Jun 2014 19:17:17 GMTcommit changed
https://trac.sagemath.org/ticket/16391#comment:21
https://trac.sagemath.org/ticket/16391#comment:21
<ul>
<li><strong>commit</strong>
changed from <em>6e3c6856da596aa0b05c82c2f3cbcf48dbd3812a</em> to <em>52c2de8586d29cbe302bb9a451589ca5d8eeadd5</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=52c2de8586d29cbe302bb9a451589ca5d8eeadd5"><span class="icon"></span>52c2de8</a></td><td><code>trac #16391: Removing the holes</code>
</td></tr></table>
TicketncohenSat, 07 Jun 2014 19:26:52 GMT
https://trac.sagemath.org/ticket/16391#comment:22
https://trac.sagemath.org/ticket/16391#comment:22
<p>
Back to needs_review !
</p>
<p>
Nathann
</p>
TicketncohenSat, 07 Jun 2014 19:26:58 GMTstatus changed
https://trac.sagemath.org/ticket/16391#comment:23
https://trac.sagemath.org/ticket/16391#comment:23
<ul>
<li><strong>status</strong>
changed from <em>needs_info</em> to <em>needs_review</em>
</li>
</ul>
TicketvdelecroixSat, 07 Jun 2014 19:33:42 GMT
https://trac.sagemath.org/ticket/16391#comment:24
https://trac.sagemath.org/ticket/16391#comment:24
<p>
Ouch. I had a commit for that...
</p>
<ul><li>why are you using tuples instead of lists?
</li><li>there is a problem for holes_sizes=(1,)
</li></ul><p>
You can look at what I did at u/vdelecroix/16391
</p>
<p>
Vincent
</p>
TicketncohenSat, 07 Jun 2014 21:40:16 GMT
https://trac.sagemath.org/ticket/16391#comment:25
https://trac.sagemath.org/ticket/16391#comment:25
<p>
Yo !
</p>
<blockquote class="citation">
<ul><li>why are you using tuples instead of lists?
</li></ul></blockquote>
<p>
What do you mean ? For the caching ? If so, that's because you get an exception when a @cached_method gets a non-hashable input.
</p>
<blockquote class="citation">
<ul><li>there is a problem for holes_sizes=(1,)
</li></ul></blockquote>
<p>
<code>O_o</code>
</p>
<p>
Funny. I fixed it, but I am pretty sure I had fixed it before in the very same way/trick. Weird <code>O_o</code>
</p>
<p>
Nathann
</p>
TicketgitSat, 07 Jun 2014 21:40:43 GMTcommit changed
https://trac.sagemath.org/ticket/16391#comment:26
https://trac.sagemath.org/ticket/16391#comment:26
<ul>
<li><strong>commit</strong>
changed from <em>52c2de8586d29cbe302bb9a451589ca5d8eeadd5</em> to <em>d0885f7944ac0cb5f5ddb6822544f9059596ba67</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=d0885f7944ac0cb5f5ddb6822544f9059596ba67"><span class="icon"></span>d0885f7</a></td><td><code>trac #16391: bugfix</code>
</td></tr></table>
TicketncohenSun, 08 Jun 2014 07:37:48 GMT
https://trac.sagemath.org/ticket/16391#comment:27
https://trac.sagemath.org/ticket/16391#comment:27
<p>
Oh. I had fixed it in "trac <a class="closed ticket" href="https://trac.sagemath.org/ticket/16347" title="enhancement: Wilson's constructions of OA with 2 truncated groups (closed: fixed)">#16347</a>: Genelarized Wilson construction" <code>:-P</code>
</p>
<p>
Nathann
</p>
TicketvdelecroixSun, 08 Jun 2014 09:45:38 GMT
https://trac.sagemath.org/ticket/16391#comment:28
https://trac.sagemath.org/ticket/16391#comment:28
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/16391#comment:25" title="Comment 25">ncohen</a>:
</p>
<blockquote class="citation">
<p>
Yo !
</p>
<blockquote class="citation">
<ul><li>why are you using tuples instead of lists?
</li></ul></blockquote>
<p>
What do you mean ? For the caching ? If so, that's because you get an exception when a @cached_method gets a non-hashable input.
</p>
</blockquote>
<p>
I mean for the output!
</p>
TicketncohenSun, 08 Jun 2014 09:55:02 GMT
https://trac.sagemath.org/ticket/16391#comment:29
https://trac.sagemath.org/ticket/16391#comment:29
<p>
Oh. I see. Then, that's because if you cache the output of a function and that this output is mutable, there is no certainty that users will not change the content of the cache by modifying the result returned by the function.
</p>
<p>
That's why I was forced to convert to "tuple" the output of <code>orthogonal_array</code> in <a class="closed ticket" href="https://trac.sagemath.org/ticket/16347" title="enhancement: Wilson's constructions of OA with 2 truncated groups (closed: fixed)">#16347</a>, which I totally hate. But I will rewrite this to only cache the boolean values, I will implement this manually as soon as all the dependencies are reviewed.
</p>
<p>
That's also why it is painful to not be able to cache only what you want.
</p>
<p>
Nathann
</p>
TicketncohenSun, 08 Jun 2014 09:55:59 GMT
https://trac.sagemath.org/ticket/16391#comment:30
https://trac.sagemath.org/ticket/16391#comment:30
<pre class="wiki">sage: @cached_function
....: def a():
....: return []
....:
sage: a()
[]
sage: x=a()
sage: x.append(8)
sage: a()
[8]
</pre>
TicketvdelecroixSun, 08 Jun 2014 17:08:54 GMT
https://trac.sagemath.org/ticket/16391#comment:31
https://trac.sagemath.org/ticket/16391#comment:31
<p>
Hi,
</p>
<p>
Some small changes in u/vdelecroix/16391 (above your last commit). The modification of the <code>NOTE</code> is the most important one (it was wrong before).
</p>
<p>
I really do not like the fact that <code>designs.orthogonal_array</code> return list of lists while <code>designs.incomplete_orthogonal_array</code> returns tuple of tuples. Can we make all tuple of tuples (at least in a later ticket)?
</p>
<p>
Beyond that, I am happy with the ticket.
</p>
<p>
Vincent
</p>
<p>
PS: the search of disjoint blocks for the OA(4,10) is <strong>much</strong> faster using increasing values of <code>x</code> instead of a <code>set_objective</code>...
</p>
TicketncohenSun, 08 Jun 2014 18:35:01 GMT
https://trac.sagemath.org/ticket/16391#comment:32
https://trac.sagemath.org/ticket/16391#comment:32
<p>
Yo !
</p>
<blockquote class="citation">
<p>
Some small changes in u/vdelecroix/16391 (above your last commit). The modification of the <code>NOTE</code> is the most important one (it was wrong before).
</p>
</blockquote>
<p>
Was it ? I thought that your version was wrong too, so I added a commit. What do you think ?
</p>
<blockquote class="citation">
<p>
I really do not like the fact that <code>designs.orthogonal_array</code> return list of lists while <code>designs.incomplete_orthogonal_array</code> returns tuple of tuples. Can we make all tuple of tuples (at least in a later ticket)?
</p>
</blockquote>
<p>
I do not want any of them to be tuples. I have no other choice but to make them tuples because nobody is willing to review <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/16353" title="enhancement: A cached_function with selective memory (needs_work)">#16353</a> which would let me cache only boolean answers (meaning that the constructors could all return lists of lists as it would be best).
</p>
<p>
If <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/16353" title="enhancement: A cached_function with selective memory (needs_work)">#16353</a> is not reviewed I will have no other choice but to implement a chaching method for all three constructors (with a common cache) for booleans answers, and of course yet another one for this function.
</p>
<p>
Which is a sheer waste of time.
</p>
<blockquote class="citation">
<p>
Beyond that, I am happy with the ticket.
</p>
</blockquote>
<p>
Tell me if you are okay with this additional commit !
</p>
<blockquote class="citation">
<p>
PS: the search of disjoint blocks for the OA(4,10) is <strong>much</strong> faster using increasing values of <code>x</code> instead of a <code>set_objective</code>...
</p>
</blockquote>
<p>
That's because when you give it the number of disjoint blocks it does not have to prove that you cannot find a strictly larger set of blocks by itself. If <code>k</code> is the largest amount of disjoint blocks in a <code>OA(4,10)</code> try with value <code>k+1</code>. Should take the same time.
</p>
<p>
Nathann
</p>
TicketgitSun, 08 Jun 2014 18:35:55 GMTcommit changed
https://trac.sagemath.org/ticket/16391#comment:33
https://trac.sagemath.org/ticket/16391#comment:33
<ul>
<li><strong>commit</strong>
changed from <em>d0885f7944ac0cb5f5ddb6822544f9059596ba67</em> to <em>41a9a247df5925a7067421a03093b0bc01155671</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=c1de59747d1c2c27ffdc586f9e91bc178eb4cc88"><span class="icon"></span>c1de597</a></td><td><code>trac #16391: doc clean + remove some list construction</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=41a9a247df5925a7067421a03093b0bc01155671"><span class="icon"></span>41a9a24</a></td><td><code>trac #16391: Typo</code>
</td></tr></table>
TicketvdelecroixMon, 09 Jun 2014 07:43:06 GMT
https://trac.sagemath.org/ticket/16391#comment:34
https://trac.sagemath.org/ticket/16391#comment:34
<p>
Hi Nathann,
</p>
<p>
I do not agree with your corrections. By definition, the holes are subsets of the ground set <code>V = {0,...,n-1}</code>. Perhaps it depend on where we read the definition.
</p>
<p>
Could we just get rid of the caching and return list of lists in the very same way as <code>orthogonal_array</code>? The time needed to find 3 disjoint blocks is not big compared to the time you need to build an orthogonal array. It would make more sense to implement the caching at the level of <code>orthogonal_array</code>. And I think, it would better if done in another ticket.
</p>
<p>
Vincent
</p>
TicketncohenMon, 09 Jun 2014 07:56:19 GMT
https://trac.sagemath.org/ticket/16391#comment:35
https://trac.sagemath.org/ticket/16391#comment:35
<p>
Yo !
</p>
<blockquote class="citation">
<p>
I do not agree with your corrections. By definition, the holes are subsets of the ground set <code>V = {0,...,n-1}</code>. Perhaps it depend on where we read the definition.
</p>
</blockquote>
<p>
Well, I did not find definition of incomplete OA in the handbook though they define incomplete transversal designs, and for this they introduce sets <code>H_1,H_2, ...</code>. Well, to define a hole in general you need to give a subset for each column... Your phrasing assumes that the OA has been relabelled so that the coordinates of the hole are the same in every column... But honestly everybody would understand it the way it is, adding this <code>^k</code> just emphasizes that we give the coordinate for every column.
</p>
<blockquote class="citation">
<p>
Could we just get rid of the caching and return list of lists in the very same way as <code>orthogonal_array</code>?
</p>
</blockquote>
<p>
Don't you want to review <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/16353" title="enhancement: A cached_function with selective memory (needs_work)">#16353</a> ? This would make everything MUCH easier.
</p>
<p>
I am willing to implement this correctly and -- if posible -- uniformly, but if people refuse to review stuff like <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/16353" title="enhancement: A cached_function with selective memory (needs_work)">#16353</a> for theological reasons then I am stuck, and I have no other way but to find workarounds.
</p>
<p>
In the constructions I will add when all this will be reviewed this function is called often. You can see that it will be called by the new version of Wilson's theorem, because holes are realy needed there. And it will be good to have it cached.
</p>
<blockquote class="citation">
<p>
The time needed to find 3 disjoint blocks is not big compared to the time you need to build an orthogonal array. It would make more sense to implement the caching at the level of <code>orthogonal_array</code>. And I think, it would better if done in another ticket.
</p>
</blockquote>
<p>
Come on man. All the boolean answers should be cached. It costs nothing, and it can only help.
</p>
<p>
Nathann
</p>
TicketgitMon, 09 Jun 2014 08:09:54 GMTcommit changed
https://trac.sagemath.org/ticket/16391#comment:36
https://trac.sagemath.org/ticket/16391#comment:36
<ul>
<li><strong>commit</strong>
changed from <em>41a9a247df5925a7067421a03093b0bc01155671</em> to <em>42239ccc8b169e1aaf148da90b638004a09e67c6</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=42239ccc8b169e1aaf148da90b638004a09e67c6"><span class="icon"></span>42239cc</a></td><td><code>trac #16391: Undoing stuff</code>
</td></tr></table>
TicketncohenMon, 09 Jun 2014 08:11:57 GMT
https://trac.sagemath.org/ticket/16391#comment:37
https://trac.sagemath.org/ticket/16391#comment:37
<p>
Here it is. Note that Wilson's decomposition as it is implemented in <a class="closed ticket" href="https://trac.sagemath.org/ticket/16347" title="enhancement: Wilson's constructions of OA with 2 truncated groups (closed: fixed)">#16347</a> was making <code>orthogonal_array</code> return tuples too.
</p>
<p>
And I will still need <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/16353" title="enhancement: A cached_function with selective memory (needs_work)">#16353</a> to update this properly. It is better to output lists than tuples, but if we cannot cache resuls we cannot even build the MOLS table once that <a class="closed ticket" href="https://trac.sagemath.org/ticket/16347" title="enhancement: Wilson's constructions of OA with 2 truncated groups (closed: fixed)">#16347</a> will be implemented --> too slow.
</p>
<p>
Nathann
</p>
TicketvdelecroixMon, 09 Jun 2014 09:15:32 GMTstatus changed
https://trac.sagemath.org/ticket/16391#comment:38
https://trac.sagemath.org/ticket/16391#comment:38
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/16391#comment:35" title="Comment 35">ncohen</a>:
</p>
<blockquote class="citation">
<p>
Yo !
</p>
<blockquote class="citation">
<p>
I do not agree with your corrections. By definition, the holes are subsets of the ground set <code>V = {0,...,n-1}</code>. Perhaps it depend on where we read the definition.
</p>
</blockquote>
<p>
Well, I did not find definition of incomplete OA in the handbook though they define incomplete transversal designs, and for this they introduce sets <code>H_1,H_2, ...</code>. Well, to define a hole in general you need to give a subset for each column... Your phrasing assumes that the OA has been relabelled so that the coordinates of the hole are the same in every column... But honestly everybody would understand it the way it is, adding this <code>^k</code> just emphasizes that we give the coordinate for every column.
</p>
</blockquote>
<p>
I had a look at various papers and they define holes as subset of <code>V</code>. But I agree, it is fine the way you did.
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
Could we just get rid of the caching and return list of lists in the very same way as <code>orthogonal_array</code>?
</p>
</blockquote>
<p>
Don't you want to review <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/16353" title="enhancement: A cached_function with selective memory (needs_work)">#16353</a> ? This would make everything MUCH easier.
</p>
</blockquote>
<p>
I can review it, but I do not want to see it used in designs!
</p>
<blockquote class="citation">
<p>
I am willing to implement this correctly and -- if posible -- uniformly, but if people refuse to review stuff like <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/16353" title="enhancement: A cached_function with selective memory (needs_work)">#16353</a> for theological reasons then I am stuck, and I have no other way but to find workarounds.
</p>
<p>
In the constructions I will add when all this will be reviewed this function is called often. You can see that it will be called by the new version of Wilson's theorem, because holes are really needed there. And it will be good to have it cached.
</p>
</blockquote>
<p>
All right. Then I will changed my mind at this point.
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
The time needed to find 3 disjoint blocks is not big compared to the time you need to build an orthogonal array. It would make more sense to implement the caching at the level of <code>orthogonal_array</code>. And I think, it would better if done in another ticket.
</p>
</blockquote>
<p>
Come on man. All the boolean answers should be cached. It costs nothing, and it can only help.
</p>
</blockquote>
<p>
No. We should cache a dictionnary <code>n -> (k_exists,k_unknown)</code>. This would be more efficient. Sometimes you have a TD(k+5,n) but was looking for a TD(k,n), so you loose information. Similarly, if you start caching (incomplete) orthogonal array you would only cache the one which has the maximum number of holes with respect to a fixed k or the on which has the maximum size with respect to a fixed set of holes.
</p>
<p>
Vincent
</p>
TicketncohenMon, 09 Jun 2014 09:20:28 GMT
https://trac.sagemath.org/ticket/16391#comment:39
https://trac.sagemath.org/ticket/16391#comment:39
<p>
Yo !
</p>
<blockquote class="citation">
<p>
I had a look at various papers and they define holes as subset of <code>V</code>. But I agree, it is fine the way you did.
</p>
</blockquote>
<p>
Thanks.
</p>
<blockquote class="citation">
<p>
I can review it, but I do not want to see it used in designs!
</p>
</blockquote>
<p>
....
</p>
<p>
It's cool to say "I do not want to see it used in design" but I am still the one who writes the code. Having this generic cache would make stuff better. And you can't really refuse an improvement because "there would be a better way to implement it" that you expect me to implement instead.
</p>
<p>
Pfffff...
</p>
<p>
Spoiled reviewers...
</p>
<blockquote class="citation">
<p>
No. We should cache a dictionnary <code>n -> (k_exists,k_unknown)</code>. This would be more efficient. Sometimes you have a TD(k+5,n) but was looking for a TD(k,n), so you loose information. Similarly, if you start caching (incomplete) orthogonal array you would only cache the one which has the maximum number of holes with respect to a fixed k or the on which has the maximum size with respect to a fixed set of holes.
</p>
</blockquote>
<p>
I know, I told you about it myself.
</p>
<p>
...
</p>
<p>
I will do it.
</p>
<p>
It just takes time, and I have been stuck for 5 weeks with a straightforward code that does not get reviewed, and I can't add patch over patch over patch forever, knowing that names and specifications will change in the dependencies. It would have been done already otherwise.
</p>
<p>
Nathann
</p>
TicketncohenMon, 09 Jun 2014 09:21:51 GMT
https://trac.sagemath.org/ticket/16391#comment:40
https://trac.sagemath.org/ticket/16391#comment:40
<p>
Could you add your name as a reviewer ?
</p>
<p>
Nathann
</p>
TicketvdelecroixMon, 09 Jun 2014 09:29:10 GMT
https://trac.sagemath.org/ticket/16391#comment:41
https://trac.sagemath.org/ticket/16391#comment:41
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/16391#comment:40" title="Comment 40">ncohen</a>:
</p>
<blockquote class="citation">
<p>
Could you add your name as a reviewer ?
</p>
</blockquote>
<p>
Ha! I always forgot that.
</p>
TicketvdelecroixMon, 09 Jun 2014 09:29:26 GMTreviewer set
https://trac.sagemath.org/ticket/16391#comment:42
https://trac.sagemath.org/ticket/16391#comment:42
<ul>
<li><strong>reviewer</strong>
set to <em>Vincent Delecroix</em>
</li>
</ul>
TicketncohenMon, 09 Jun 2014 12:53:23 GMT
https://trac.sagemath.org/ticket/16391#comment:43
https://trac.sagemath.org/ticket/16391#comment:43
<blockquote class="citation">
<p>
I will do it.
</p>
</blockquote>
<p>
<a class="needs_work ticket" href="https://trac.sagemath.org/ticket/16353" title="enhancement: A cached_function with selective memory (needs_work)">#16353</a>
</p>
<p>
Nathann
</p>
TicketvbraunMon, 09 Jun 2014 22:53:20 GMTstatus changed
https://trac.sagemath.org/ticket/16391#comment:44
https://trac.sagemath.org/ticket/16391#comment:44
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_work</em>
</li>
</ul>
<pre class="wiki">LaTeX Warning: Hyper reference `sage/combinat/designs/orthogonal_arrays:sage.co
mbinat.designs.orthogonal_arrays.wilson_construction' on page 2472 undefined on
input line 213303.
! Extra }, or forgotten $.
l.213341 ...ound set is always $V = \{0, ..., n-1}
$ and the
?
! Emergency stop.
l.213341 ...ound set is always $V = \{0, ..., n-1}
$ and the
! ==> Fatal error occurred, no output PDF file produced!
Transcript written on combinat.log.
make[1]: *** [combinat.pdf] Error 1
make[1]: Leaving directory `/home/release/Sage/src/doc/output/latex/en/reference/combinat'
Error building the documentation.
</pre>
TicketgitTue, 10 Jun 2014 08:08:01 GMTcommit changed
https://trac.sagemath.org/ticket/16391#comment:45
https://trac.sagemath.org/ticket/16391#comment:45
<ul>
<li><strong>commit</strong>
changed from <em>42239ccc8b169e1aaf148da90b638004a09e67c6</em> to <em>24ac3a8e0424d9b4516517144935b0367a95801e</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=24ac3a8e0424d9b4516517144935b0367a95801e"><span class="icon"></span>24ac3a8</a></td><td><code>trac #16391: Broken doc</code>
</td></tr></table>
TicketncohenTue, 10 Jun 2014 08:08:40 GMT
https://trac.sagemath.org/ticket/16391#comment:46
https://trac.sagemath.org/ticket/16391#comment:46
<p>
Sorry for that.
</p>
<p>
Now "make doc-clean && make doc-pdf" breaks when compiling some french document, but that's unrelated.
</p>
<p>
Nathann
</p>
TicketncohenTue, 10 Jun 2014 08:08:45 GMTstatus changed
https://trac.sagemath.org/ticket/16391#comment:47
https://trac.sagemath.org/ticket/16391#comment:47
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>positive_review</em>
</li>
</ul>
TicketncohenThu, 12 Jun 2014 13:33:22 GMTdependencies changed
https://trac.sagemath.org/ticket/16391#comment:48
https://trac.sagemath.org/ticket/16391#comment:48
<ul>
<li><strong>dependencies</strong>
changed from <em>#16370</em> to <em>#16370,#16460</em>
</li>
</ul>
TicketncohenThu, 12 Jun 2014 14:11:44 GMTdependencies changed
https://trac.sagemath.org/ticket/16391#comment:49
https://trac.sagemath.org/ticket/16391#comment:49
<ul>
<li><strong>dependencies</strong>
changed from <em>#16370,#16460</em> to <em>#16460</em>
</li>
</ul>
TicketgitThu, 12 Jun 2014 14:29:54 GMTstatus, commit changed
https://trac.sagemath.org/ticket/16391#comment:50
https://trac.sagemath.org/ticket/16391#comment:50
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_review</em>
</li>
<li><strong>commit</strong>
changed from <em>24ac3a8e0424d9b4516517144935b0367a95801e</em> to <em>70c98058b2414e3fc873a8825c1db293da0709e3</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1 and set ticket back to needs_review. Last 10 new commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=6fb1f14be18c51aabb5d28427a2074b2b5470552"><span class="icon"></span>6fb1f14</a></td><td><code>trac #16295: Bugfix</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=1653790357b0668126e9a8044832c7b9c883efc9"><span class="icon"></span>1653790</a></td><td><code>trac #16295: Merged with 6.3.beta3</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=b66a187a35ff81525f42ddf4d93611ec2bd9fb6b"><span class="icon"></span>b66a187</a></td><td><code>fixed some small language typos and changed MOLS error messages into context that MOLS researchers will expect.</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=02f12476967dd287ffb47e711098a5518efbddd2"><span class="icon"></span>02f1247</a></td><td><code>trac #16295: one more doctest</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=f9690032a77345bd0d370a3099503574fbf6c96e"><span class="icon"></span>f969003</a></td><td><code>trac #16356: MOLS for n=18,57,154,276,298,342</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=917dd5c6a970b8b7b5caa7eae821124770c3c4e5"><span class="icon"></span>917dd5c</a></td><td><code>trac #16356: Merged with #16295</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=f23d39c13647376fcb12f2c1825a3053af976174"><span class="icon"></span>f23d39c</a></td><td><code>trac #16460: a cache for OA/TD/MOLS existence</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=60b717f372f4a377f946dea21824c86454d2b678"><span class="icon"></span>60b717f</a></td><td><code>trac #16460: small fixes</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=d7cb52a2eff7c3683f1557a66a5f06fa0c5225fb"><span class="icon"></span>d7cb52a</a></td><td><code>trac #16460: Merged with updated #16356</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=70c98058b2414e3fc873a8825c1db293da0709e3"><span class="icon"></span>70c9805</a></td><td><code>trac #16391: Merged with #16460</code>
</td></tr></table>
TicketncohenThu, 12 Jun 2014 14:30:06 GMTstatus changed
https://trac.sagemath.org/ticket/16391#comment:51
https://trac.sagemath.org/ticket/16391#comment:51
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
TicketvbraunSat, 14 Jun 2014 19:59:27 GMTstatus, branch changed; resolution set
https://trac.sagemath.org/ticket/16391#comment:52
https://trac.sagemath.org/ticket/16391#comment:52
<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/ncohen/16391</em> to <em>70c98058b2414e3fc873a8825c1db293da0709e3</em>
</li>
</ul>
Ticket