#15310: Wilson's construction of Transversal Designs/Orthogonal Arrays/MOLS
-------------------------+-------------------------------------------------
Reporter: | Owner:
ncohen | Status: needs_review
Type: | Milestone: sage-6.2
enhancement | Resolution:
Priority: major | Merged in:
Component: | Reviewers:
combinatorics | Work issues:
Keywords: | Commit:
Authors: | d74341411288315f13da3d4383e515b884ba7440
Nathann Cohen | Stopgaps:
Report Upstream: N/A |
Branch: |
u/ncohen/15310 |
Dependencies: |
#15287, #15431 |
-------------------------+-------------------------------------------------
Comment (by brett):
I will jump in here. Julian Able's other versions of Wilson's
construction are the ones discussed in the Colbourn and Dinitz reference.
I was wrong about the details when I chatted with Vincent: I said they
simplified when $u$ was a nice value, but your posted email from Julian
reminds me that these are multiple truncations. I do not think these need
to go into a first round. I would advocate getting the basic Wilson's
theorem into the official Sage release and then adding more intricate
variations
With regards to the product construction, I think that when Wilson's
construction is passed $u=0$ then it should not check that TD$(k+1,t)$,
TD$(k,u)$, TD$(k,m+1)$ exist at all. It should check that TD(k,t)$ and
$TD(k,m)$ exist and call the product construction. Then in your
find_wilson_decomposition you should also include $u=0$ in the search
loops
I am waiting for sage to compile, then I will get the new commit and look
more closely at the code.
Here are some additional thoughts that apply to the whole TD/OA enterprise
rather than just this patch (If I should be discussing these things
somewhere else because they are more general comments then please let me
know and point me to where to have this discussion)
- (anticipating ticket #16231) the OA/TD/MOLS object should have a single
internal format and then constructor operations to output other equivalent
objects. I think OA is the most general since it can have arbitrary $t$
(Which TD does not) and arbitrary $\lambda$ (which MOLS cannot have), etc.
I think all internal operations should be done on OAs; that is all
constructions are as OAs. Then the object should be able to output a TD
or MOLS as alternatives. The user should be able to call for whichever
object they want but this would be just a case now of doing a sanity check
(make sure $t=2$ of they asked for TD), translate the parameters to OA
parameters, find the object if possible, and translate it into the desired
output format. This single internal format would eliminate the
possibility of methods eventually trying to call themselves again. But
the users will get the experience they expect with each type of object.
- There are number of known parameters which cannot exist. The Bruck Ryser
Chowla Theorm gives the non-existence of many TD(n+1,n). Additionally C.
Lam proved that TD(11,10) cannot exist. Finally there is some work that
shows that if $k$ is large enough then the existence of TD$(k,n)$ implies
the existence of TD$(n+1,n)$ and so the non-existence results can
percolate downwards in $k$. I do not think we should have all of the
known results in this change. We should only implement the easy ones or
possibly none at all at first
--
Ticket URL: <http://trac.sagemath.org/ticket/15310#comment:29>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
