#16391: Helper functions for OA constructions
-------------------------------------+-------------------------------------
Reporter: ncohen | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.3
Component: combinatorial | Resolution:
designs | Merged in:
Keywords: | Reviewers:
Authors: Nathann Cohen | Work issues:
Report Upstream: N/A | Commit:
Branch: u/ncohen/16391 | 90f828fb2904fc5083baa8b45af97d6dc7740f54
Dependencies: #16370 | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by vdelecroix):
Hello,
Replying to [comment:14 ncohen]:
> Yo !
>
> > 1) What you called OA with holes are "incomplete orthogonal array" in
the Handbook
>
> 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.
>
> Note that I have no clue how I could compute a decomposition of a TD
with holes of size > 1. No idea.
For now, we do not care. But there are examples and references in the
Handbook.
> Okay, then we can implement it like that :
`incomplete_transversal_design(k,n,tuple_of_hole_sizes,OA=None)`.
>
> The function would return an exception whenever there is an element in
tuple_of_hole_sizes which is not equal to 1, and if `OA` is defined then
it is the OA that will be used to compute the holes ?
Perfect. It is a bit dummy but it is more terminology compliant and lets
the door open.
> > 2) From the function you wrote, it is very easy to
> > - allow `x` as None, in which case the function tries to optimize the
number of holes
>
> Holes of size 1.
yes. my mistake.
> > - have an optional argument `OA` such that, if it is provided, the
function looks for holes inside this orthogonal array.
>
> Yepyep.
>
> > 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.
>
> 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 `Graph.independent_set`.
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).
> > A perhaps cleaner way to do things is to have two functions that would
looks like
> > - `incomplete_orthogonal_array(k,n,holes)` (this function would be
available from the global namespace)
>
> Yepyep, this could be `designs.incomplete_orthogonal_array`
Great!
> > - `look_for_holes_in_my_OA(OA,k,n,holes)`
>
> I would not know where to write that. It does not belong to
`designs.<tab>`. We could write it somewhere in the `orthogonal_array`
file, to let it be exposed later when all this will have become a class.
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 `graphs.OrthogonalArrayBlockGraph` does. Perhaps a
more appropriate name would be, `OA_find_disjoint_block`?
Vincent
--
Ticket URL: <http://trac.sagemath.org/ticket/16391#comment:15>
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.
