Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#15431 closed enhancement (fixed)

Transversal Design TD(6,12)

Reported by: ncohen Owned by:
Priority: major Milestone: sage-6.2
Component: combinatorics Keywords: designs
Cc: wdj, rbeezer, brett, dimpase Merged in:
Authors: Nathann Cohen Reviewers: Vincent Delecroix
Report Upstream: N/A Work issues:
Branch: a86b08e (Commits) Commit:
Dependencies: #15287 #15368 Stopgaps:

Description (last modified by ncohen)

A construction for TD(6,12) (needed for the general construction of BIBD with k=5)

Change History (40)

comment:1 Changed 5 years ago by ncohen

  • Branch set to u/ncohen/15431
  • Cc wdj rbeezer brett dimpase added
  • Dependencies set to #15287 #15368
  • Description modified (diff)
  • Status changed from new to needs_review

comment:2 Changed 5 years ago by git

  • Commit set to 6fbef0c97f1c88dd9c0ace0cf1a1d67852fd3304

Branch pushed to git repo; I updated commit sha1. Last 10 new commits:

6fbef0ctrac #15431 : Construction of TD(6,12)
ec6c09etrac #15431: depends on #15368
79ea502trac #15431: depends on #15287
0ad88a6Additions to groups.misc : AdditiveAbelian?, Free, Braid, SemimonomialTransformation?
3d75bd3Move QuaternionMatrixGroupGF3 from groups.misc to groups.matrix
2a68051Add affine groups to groups.<tab>
017084fBroken link in groups catalog doc
59f340bOrthogonal arrays -- doctest
e32c6deOrthogonal arrays -- bugfix
7c1b651Orthogonal arrays

comment:3 Changed 5 years ago by vbraun_spam

  • Milestone changed from sage-6.1 to sage-6.2

comment:4 Changed 5 years ago by git

  • Commit changed from 6fbef0c97f1c88dd9c0ace0cf1a1d67852fd3304 to c87cac5f35036a820f877ab891eb35cffa1784a1

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

bbc682atrac #15287: merge with updated #15286
23bc728Merge branch 'u/ncohen/15287' of trac.sagemath.org:sage into u/tscrim/15287
8bae37eReview changes to orthogonal_arrays.py.
849598eLast minor tweak.
c87cac5trac #15431: rebase on updated #15287

comment:5 Changed 5 years ago by vdelecroix

Hi Nathan,

Few remarks that would me help me for the review

  • In the function transversal_desing
    • the arguments are ordered k,n but in the definition n,k is used.
    • could you give the definition with t
  • In the function orthogonal_arrays
    • you should defined what is a (k,n,t) orthogonal array.
    • the documentation says that only t=2 is available but it does not prevent you to define it in that generality.
    • I guess that if k >= n+t there is no (k,n,t) orthogonal array. Do you know that ? If this is true, please more explicit in the error rather than NotImplementedError: I don't know how to build this orthogonal array!" I would prefer "EmptySetError: there exist no (k,n,t) orthogonal array with k >= n+t"

comment:6 Changed 5 years ago by ncohen

Hello !

I just answered all your comments in the code. About the last one : it is true that k > n+1 is impossible when t=2, and this holds because of the equivalence with MOLS, but I don't see how you prove it for any larger t ?... As we only handle t=2 in the code, I changed the error message in this case.

I want to do many things with this design code, but being the only fan is a problem here : it is very hard to have these patches reviewed (thank you very much again for doing it !). The thing is that there are equivalences between TD,OA,MOLS, and that some constructions (like wilson's construction in #15310) are very powerful ways to generate new objects. So we must have an automatic way to check if Sage knows of to build an equivalent OA when it has no construction for a specific MOLS, and conversely, and the same with TD. Thus in the end, I would love it if the error message "Such a design does not exist" which is written in the MOLS would automatically yield the same message on the Orthogonal Array side :-)

But I would like to have Wilson's construction inside of Sage first. And perhaps another product construction I need for the BIBD with k=5. Ahahahah. Long road :-)

Anyway here is the commit, and sorry for those missing definitions.

Nathann

comment:7 Changed 5 years ago by git

  • Commit changed from c87cac5f35036a820f877ab891eb35cffa1784a1 to a02aa52e638e571525099c88537571bac5362e61

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

ba232b6trac #15431: rebase on 6.2.beta6
a02aa52trac #15431: Reviewer's remarks

comment:8 Changed 5 years ago by ncohen

You were right ! :-)

Nathann

comment:9 Changed 5 years ago by git

  • Commit changed from a02aa52e638e571525099c88537571bac5362e61 to 4adf6b5792919daea356c66d511fc621776d0a77

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

4adf6b5trac #15431: Reviewer's remark II

comment:10 follow-up: Changed 5 years ago by vdelecroix

Hi Nathann,

I am very happy with the EmptySetError. Could you raise it *before* the check t=2 ?

OA and TD are the same objects up to relabeling. More precisely, an OA is a TD with sets V1 = V2 = ... = Vn = [n] whereas you choose the convention V1 = [n], V2 = [n,2n], ... for the TD. I do not see the point of having two different functions... please tell me.

It seems that backtracking might be an approach to build TD when there are no other constructions. It might also be helpful to build all TD up to isomorphism. Do you know how hard would it be ?

Curiosity question: if you build a TD with k=n+t-1 do we know if for any two Si, Sj their intersection has t-1 elements ? (answering yes would help the backtracking)

comment:11 in reply to: ↑ 10 ; follow-up: Changed 5 years ago by ncohen

Hellooooo !

I am very happy with the EmptySetError. Could you raise it *before* the check t=2 ?

I believe it is already the case in the branch.

OA and TD are the same objects up to relabeling.

Yep !

More precisely, an OA is a TD with sets V1 = V2 = ... = Vn = [n] whereas you choose the convention V1 = [n], V2 = [n,2n], ... for the TD. I do not see the point of having two different functions... please tell me.

Well, I have two because I implemented all this while reading books and fishing for the theorems I needed. It is true that they are the same, and there is also a bijection between orthogonal arrays with t=2 and mutually orthogonal latin squares. That's why I would like to "implement the theorem" that "There exists a TD iif there exists a OA iif there exists a MOLS", and make sure that if one of the three functions can build something then the two others can build the corresponding object.

Why a TD and a OA ? Well, because the books talk of both. Sometimes the same book talks of the two things, and sometimes you do not want to do this relabeling by yourself. They are the same objects (as well as MOLS) and so the code must not repeat itself, but the two objects exist in the book and so I think the two objects should exist here too.

As any construction of a MOLS or OA or TD can be translated into a construction of another of the three, it is technically possible to have only one main function, and two "translating" functions when needed. But those constructions I found in books are already quite unclear, there is already a lot of relabelling being done "silently" in the constructions, and I thought it could only help to write the constructions in their original formalism instead of translating them. Plus it would really be a pain to translate all the proofs while reading them, what I wrote was not thaaaaat easy to translate into code already :-P

It seems that backtracking might be an approach to build TD when there are no other constructions. It might also be helpful to build all TD up to isomorphism. Do you know how hard would it be ?

I have got no idea on earth. This stuff scares me. For me eveything which is related to designs is black magic.

Curiosity question: if you build a TD with k=n+t-1 do we know if for any two Si, Sj their intersection has t-1 elements ? (answering yes would help the backtracking)

What are Si and Sj ?

Nathann

comment:12 Changed 5 years ago by ncohen

Ahahah. Okay, I see, the Si Sj are the sets of transversal designs. I thought that you talked of an orthogonal array and wondered if Si and Sj were rows or columns. See how easy it is ? :-P

I have absolutely no idea how to answer that, though ^^;

Nathann

comment:13 in reply to: ↑ 11 ; follow-up: Changed 5 years ago by vdelecroix

Replying to ncohen:

Hellooooo !

I am very happy with the EmptySetError. Could you raise it *before* the check t=2 ?

I believe it is already the case in the branch.

Nope. Look line 200 and 203.

OA and TD are the same objects up to relabeling.

Yep !

More precisely, an OA is a TD with sets V1 = V2 = ... = Vn = [n] whereas you choose the convention V1 = [n], V2 = [n,2n], ... for the TD. I do not see the point of having two different functions... please tell me.

I was not arguing about MOLS which for me looks really different. TD and OA are the very same up to a stupid relabeling. Please do not argue about MOLS, I want to leave them for now.

Why a TD and a OA ? Well, because the books talk of both. Sometimes the same book talks of the two things, and sometimes you do not want to do this relabeling by yourself. They are the same objects (as well as MOLS) and so the code must not repeat itself, but the two objects exist in the book and so I think the two objects should exist here too.

This is an argument for having two entry points but not having two places where to find the code.

As any construction of a MOLS or OA or TD can be translated into a construction of another of the three, it is technically possible to have only one main function, and two "translating" functions when needed. But those constructions I found in books are already quite unclear, there is already a lot of relabelling being done "silently" in the constructions, and I thought it could only help to write the constructions in their original formalism instead of translating them. Plus it would really be a pain to translate all the proofs while reading them, what I wrote was not thaaaaat easy to translate into code already :-P

I believe this was not easy, but my job is review. And it should be clear for anybody who reads the code why there are two different functions TD and OA. With the definition you gave in the documentation a OA *is* a TD. On the other hand, look at the code of transversal_design... it is almost empty except TD6_12 which is the reason of this patch. I do not see any reason for having different functions at this point. Do you think transversal_design will get bigger ?

comment:14 in reply to: ↑ 13 Changed 5 years ago by ncohen

Nope. Look line 200 and 203.

    if k < 2:
        raise ValueError("undefined for k less than 2")

    elif k >= n+t:
        from sage.categories.sets_cat import EmptySetError
        # When t=2 then k<n+t as it is equivalent to the existence of n-1 MOLS.                                                                                                                
        # When t>2 the submatrix defined by the rows whose first t-2 elements                                                                                                                  
        # are 0s yields a OA with t=2 and k-(t-2) columns. Thus k-(t-2) < n+2,                                                                                                                 
        # i.e. k<n+t.                                                                                                                                                                          
        raise EmptySetError("No Orthogonal Array exists when k>=n+t")

    elif t != 2:
        raise NotImplementedError("only implemented for t=2")

You can also see this by clicking on the branch's name at the head of the ticket. I moved this t != 2 in an earlier commit.

I was not arguing about MOLS which for me looks really different. TD and OA are the very same up to a stupid relabeling. Please do not argue about MOLS, I want to leave them for now.

I was just saying that those are all equivalent objects up to some relabelling...

This is an argument for having two entry points but not having two places where to find the code.

Well... I saw a construction for a transversal design, I added it to the constructor of transversal designs. What is the problem with having two places with code, given that we will have some code in MOLS and in TD at the same time ?

I mention those MOLS again because I would have agreed with your if we only had TD and OA. It is too similar to have one which is not just a translating function for the other, but given that we are more or less forced to have two versions already, I do not see what would keep us from having a third one.

I believe this was not easy, but my job is review. And it should be clear for anybody who reads the code why there are two different functions TD and OA. With the definition you gave in the documentation a OA *is* a TD.

As well as a MOLS.

On the other hand, look at the code of transversal_design... it is almost empty except TD6_12 which is the reason of this patch. I do not see any reason for having different functions at this point. Do you think transversal_design will get bigger ?

Well, I have a product function for transversal designs to add as part of the general BIBD with k=5 construction. Not very long, and it can obviously be rewritten as a TD or a MOLS.

Really, as we are already forced to accept that code will be spread into at least two functins, MOLS and TD or OA, I just don't mind a third one, given that some code is written to make them communicate.

And in the end writing code for these objects gets easier : implement a TD if you want a TD, implement an OA if you want an OA, etc ...

Nathann

comment:15 Changed 5 years ago by ncohen

Though perhaps I should tell you what I have in mind for these files :

I do not like to have so many "if" in the functions.. Really, each "if" actually means "try this construction, and if it failed try this one, and if it failed try this one". As a result you have a lot of very different constructions in the same place, and it is hard to document them individually.

Besides, the code will get worse because of #15310, because I need to add an argument to TD/OA : "do not build the design, just tell me if you can do it". This is useful because Wilson's construction is recursive, and because you do not want to build stuff that you may not be able to use in the end.

This, in each of these "if" which try some construction, you also have to handle the case where you only want to return a boolean answer, or return the best MOLS you can build, stuff like that.

And it does get messy.

So what I thought is something like this : write three decorators

@mols_construction
@td_construction
@oa_construction

And when the @mols_construction is applied to a function F (defined anywhere in the file), then F is added to a global index of "mols constructions".

And then, the code of "MOLS(k,n)" becomes "For every constructor in the global list, give it a try and answer if it returns something useful".

As you can see, the TD6_12 is a function of its own, and it is only called in the constructor of TD. It's either this, or add the documentation of the different constructions in the doc of transversal_design, and that does not scale.

Nathann

comment:16 Changed 5 years ago by git

  • Commit changed from 4adf6b5792919daea356c66d511fc621776d0a77 to 47ffd9153b474fbf2b4f560e726b0cfdbcb0af53

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

47ffd91trac #15431: remove old todo

comment:17 Changed 5 years ago by ncohen

The commit I just uploaded removes a "todo" from combinat.py, saying that a MOLS command should be exposed from GAP (package guava). I remove it for its documentation (http://www.gap-system.org/Manuals/pkg/guava-3.12/htm/chap5.html#X81B7EE4279398F67) says that this function can only return MOLS of size qxq when q is a power of a prime number, in which case the code from designs.mutually_orthogonal_latin_squares already implement the best result possible (i.e. n-1 MOLS).

Nathann

comment:18 follow-up: Changed 5 years ago by vdelecroix

Thank you for the explanations. But still, with your definition given in the doc of TD, the functions TD and OA return particular cases of transversal desings (since you do not let the user choose his sets V1, V2, ...). I found it very confusing having two functions basically doing the same job.

Could you state in both documentations that an OA is a TD and vice versa ? Could you put in the doc of TD that you choose to use the sets V1 = [0,n-1], V2 = [n,2n-1], ... and it would be even nicer inside the doc to have examples involving:

sage: oa_to_td = lambda x: return [[i*n + c for ...] ...]
sage: td_to_oa = lambda x: return [[(j-c)//n for ...] ...]

That way, it is clear that is just a convenience for the programmer.

comment:19 in reply to: ↑ 18 Changed 5 years ago by ncohen

Okay, back to the beginning.

A long time ago, you asked me to change the definition of transversal design to add the parameter t. I did it, because to me a TD and an OA are equivalent things, but it turns out that it is a mistake, a TD is a vision of an OA with t=2. I just checked, and did not find any definition of a TD which is not just about pairs of elements.

So if you agree, I will revert the changes I did to the doc of TD, and TD will only handle pairs, as it seems that for everybody in the math world a TD is an OA with t=2.

Which means that the two objects are not equivalent, which means that there is no problem anymore. What do you think ?

Nathann

comment:20 Changed 5 years ago by ncohen

comment:21 Changed 5 years ago by git

  • Commit changed from 47ffd9153b474fbf2b4f560e726b0cfdbcb0af53 to 06eb5ff9b732fcc3beb917445787e21c0ec73f49

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

06eb5fftrac #15431: Back to the standard definition of TD

comment:22 Changed 5 years ago by git

  • Commit changed from 06eb5ff9b732fcc3beb917445787e21c0ec73f49 to f9aae832ba08748e7931c4d29d58fd6b80f3fc29

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

f9aae83trac #15431: Back to the standard definition of TD

comment:23 Changed 5 years ago by git

  • Commit changed from f9aae832ba08748e7931c4d29d58fd6b80f3fc29 to a537755ebc4522efd30c12c9225abfcac1d36a90

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

a537755trac #15431: Back to the standard definition of TD

comment:24 Changed 5 years ago by vdelecroix

Hi Nathann,

Is it rebased on beta7? I want to review it but without loosing 20 minutes recompiling...

comment:25 follow-up: Changed 5 years ago by vdelecroix

  • Status changed from needs_review to needs_info

Hi Nathann,

1) Let me reformulate a more general definition of TD that contains the definition of an OA (but is equivalent up to relabeling):

A TD is a subset \mathcal{S} of transversals in V_1 \times V_2 \times \ldots \times V_k such that for any given t-tuple v = (v_{i_1}, \ldots, v_{i_t}) inside V_{i_1} \times V_{i_2} \times \ldots \times V_{i_t} there exists a unique S in \mathcal{S} such that v is in S. (note that necessarily \mathcal{S} has cardinality n^t).

In your implemetation, you chose V_1 = [n], V_2 = [n,2n] etc. Actually, with the generalized definition above, you can think of an OA as a TD where V_i = [n]. The correspondence is just stupid and you already wrote it in your code:

OA2TD = lambda OA: [[i*n+c for i,c in enumerate(l)] for l in OA]
TD2OA = lambda TD: [[(j-c)//i for j,c in enumerate(l)] for k in TD]

I propose to move all the code from TD into OA and have a stupid OA2TD which does the stuff if people prefer TD labelling. Even better, you can let the user specifies his/her preferred choice of sets V1, ..., Vk as parameters in the function OA. More precisely, you would write:

TD2OA = lambda OA,V: [[V[i][c] for i,c in enumerate(l)] for l in OA]

I am happy to do the change by myself if you agree.

2) In the definition of TD and OA (on both Wolfram and Wikipedia) there is an extra parameter lambda. It is lost in your definition. Why?

comment:26 in reply to: ↑ 25 ; follow-up: Changed 5 years ago by ncohen

  • Status changed from needs_info to needs_review

Hello Vincent !

1) Let me reformulate a more general definition of TD that contains the definition of an OA (but is equivalent up to relabeling):

Hey man, I am sorry but the definition of a TD is what it is. If Sage implements a mathematical object, it has to be what people expect. I know that the objects are equivalent, the theory knows that the objects are equivalent, but they are two objects with different names and different definitions.

Why on earth would it make any sense to implement different definitions just because it makes the code easier ? That's crazy ! And WILL lead to mistakes !

The correspondence is just stupid and you already wrote it in your code:

What is this madness about ? Will you implement only one combinatorial object just because all others are in bijection with it ? This is crazy.

I am happy to do the change by myself if you agree.

No way. The definition of a TD in Sage will be the definition of a TD in Books/Wikipedia/Papers?.

2) In the definition of TD and OA (on both Wolfram and Wikipedia) there is an extra parameter lambda. It is lost in your definition. Why?

Because it is equal to 1 in all the designs, which is what people would expect. We can add it and raise an exception if anything different from 1 is given, or add in the documentation that it is assumed too be one (which, again, is what people would expect). I don't like to add parameters that cannot be changed, so I would prefer the second option.

Nathann

comment:27 in reply to: ↑ 26 ; follow-up: Changed 5 years ago by vdelecroix

Hello Nathann,

Replying to ncohen:

Hello Vincent !

1) Let me reformulate a more general definition of TD that contains the definition of an OA (but is equivalent up to relabeling):

Hey man, I am sorry but the definition of a TD is what it is. If Sage implements a mathematical object, it has to be what people expect. I know that the objects are equivalent, the theory knows that the objects are equivalent, but they are two objects with different names and different definitions.

I see your point and it seems that you partly missed what I proposed. You can make a difference between the (stupid) mathematical definitions and how you implement your objects in Sage. It saves time and make people that read the code more intelligent. My suggestion was to concentrate all the construction code as OA (and specify it in the documentation). While in TD, just call OA and do the appropriate transformation. You already told me that one of your goal is to implement dozens of design constructions. It would be easier to code and maintain if you only build OA and no TD. What do you think?

An other tiny improvement is to allow user to choose their own sets in TD (... that way, everybody see that OA is a particular case of TD ;-)

Why on earth would it make any sense to implement different definitions just because it makes the code easier ? That's crazy ! And WILL lead to mistakes !

Agree.

The correspondence is just stupid and you already wrote it in your code:

What is this madness about ? Will you implement only one combinatorial object just because all others are in bijection with it ? This is crazy.

Permutations on {0,1,2} and {a,b,c} are in trivial bijections while permutations and binary trees are in bijection but not in a trivial way.

I am happy to do the change by myself if you agree.

No way. The definition of a TD in Sage will be the definition of a TD in Books/Wikipedia/Papers?.

2) In the definition of TD and OA (on both Wolfram and Wikipedia) there is an extra parameter lambda. It is lost in your definition. Why?

Because it is equal to 1 in all the designs, which is what people would expect. We can add it and raise an exception if anything different from 1 is given, or add in the documentation that it is assumed too be one (which, again, is what people would expect). I don't like to add parameters that cannot be changed, so I would prefer the second option.

Just put a word in the definition like "Sometimes there is a useless parameter lambda in definitions, it is always 1 here."

Vincent

comment:28 in reply to: ↑ 27 Changed 5 years ago by ncohen

I see your point and it seems that you partly missed what I proposed. You can make a difference between the (stupid) mathematical definitions and how you implement your objects in Sage. It saves time and make people that read the code more intelligent. My suggestion was to concentrate all the construction code as OA (and specify it in the documentation). While in TD, just call OA and do the appropriate transformation. You already told me that one of your goal is to implement dozens of design constructions. It would be easier to code and maintain if you only build OA and no TD. What do you think?

I still think the same way. That if a paper is entitled "A new Transversal Design of parameters whatever,whatever", it would be nice to add this transversal design in Sage and not implement it as an orthogonal array, making the translation while writing the code. You cannot tell when you implement the construction if it will be called more often as a TD or as an OA, you have no idea if the translation takes a lot of time. If you worry about time, there is much more to save by making these files Cython files and working on "cdef int/list" instead of Sage integers than by moving code around.

By the way, I intend to move all the constructions *away* from the constructors of TD and OA anyway. There will only be in the constructor of OA a list of functions that can be used to build OA, and in TD a list of functions that build TD. Thus there will be no "location" for this code, it can be wherever we want. It can be clearer, and better documented.

An other tiny improvement is to allow user to choose their own sets in TD (... that way, everybody see that OA is a particular case of TD ;-)

I hope not, for in a TD all groups are disjoint sets. If the users want different labels we can do that indeed, but really ...

What is this madness about ? Will you implement only one combinatorial object just because all others are in bijection with it ? This is crazy.

Permutations on {0,1,2} and {a,b,c} are in trivial bijections while permutations and binary trees are in bijection but not in a trivial way.

I waste my health and my computer wastes cycles so that you algebraists can label the vertices of a graph with things which are not integers. Surely I can make graphs use integers only as vertices and you will deal with the relabeling yourselves ? They are in trivial bijection.

Just put a word in the definition like "Sometimes there is a useless parameter lambda in definitions, it is always 1 here."

I will do so in a second. As soon as my "make" of Sage terminates.

Nathann

comment:29 Changed 5 years ago by git

  • Commit changed from a537755ebc4522efd30c12c9225abfcac1d36a90 to b3cabbe8b9d73d0797cfdfe3264c33c58ca4b4a3

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

2d345f1trac #15431: Rebase on 6.2.beta8
b3cabbetrac #15431: Mention that we assume \lambda=1

comment:30 follow-up: Changed 5 years ago by ncohen

I thought that it made more sense to add it as a comment directly inside of the definition... What do you think ? I also added it in BalancedIncompleteBlockDesign.

Nathann

comment:31 in reply to: ↑ 30 ; follow-up: Changed 5 years ago by vdelecroix

I let you do what you want with the implementation but I am still unhappy with the documentation:

  • Reading the definition, I do not understand where lambda comes from (in both bibd and td)
  • In transversal_design you do not specify whether the groups V_i are disjoint or not. What is the convention? It should be said what is the implementation in Sage (e.g. if I am using is_transversal_design I want to know what I am testing).

comment:32 in reply to: ↑ 31 ; follow-up: Changed 5 years ago by ncohen

Yo !

  • Reading the definition, I do not understand where lambda comes from (in both bibd and td)

As you wish. What about this ?

  • In transversal_design you do not specify whether the groups V_i are disjoint or not. What is the convention? It should be said what is the implementation in Sage (e.g. if I am using is_transversal_design I want to know what I am testing).

Well, it is the convention to have them disjoint, plus I used \sqcup instead of \cup, plus you can actually deduce that they are disjoint from the definition : if two groups intersect on one element, then a set which contain it cannot have cardinality k as it must intersect each group at most once, and there are k groups.

I added a "disjoint" somewhere in the definition to make it clearer.

(e.g. if I am using is_transversal_design I want to know what I am testing).

Is there something unclear in the documentation of is_transversal_design ?

Nathann

comment:33 Changed 5 years ago by git

  • Commit changed from b3cabbe8b9d73d0797cfdfe3264c33c58ca4b4a3 to 8273741e4f9cd86c788e2769084c954c24b1c8cf

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

8273741trac #15431: Mention that we assume \lambda=1

comment:34 in reply to: ↑ 32 ; follow-up: Changed 5 years ago by vdelecroix

Replying to ncohen:

Yo !

  • Reading the definition, I do not understand where lambda comes from (in both bibd and td)

As you wish. What about this ?

Fantastic!

  • In transversal_design you do not specify whether the groups V_i are disjoint or not. What is the convention? It should be said what is the implementation in Sage (e.g. if I am using is_transversal_design I want to know what I am testing).

Well, it is the convention to have them disjoint, plus I used \sqcup instead of \cup, plus you can actually deduce that they are disjoint from the definition : if two groups intersect on one element, then a set which contain it cannot have cardinality k as it must intersect each group at most once, and there are k groups. I added a "disjoint" somewhere in the definition to make it clearer.

(e.g. if I am using is_transversal_design I want to know what I am testing).

Is there something unclear in the documentation of is_transversal_design ?

Let me mention that \sqcup does not mean that they are disjoint but that you take the disjoint union. The set A \sqcup A is perfectly valid and will have cardinality twice the one of A. So I would actually prefer a \cup if it is what you intended to do.

The documentation is much better in is_transversal_design because of the NOTE block. But there is nothing in transversal_design. Could you do a copy/paste or something.

(For me, it would be clearer for a TD to be a subset of V1 x V2 x ... x Vk but let us stick to conventions).

comment:35 in reply to: ↑ 34 ; follow-up: Changed 5 years ago by ncohen

Yo !

Let me mention that \sqcup does not mean that they are disjoint but that you take the disjoint union. The set A \sqcup A is perfectly valid and will have cardinality twice the one of A. So I would actually prefer a \cup if it is what you intended to do.

Okayyy, I updated the commit again to remove those sq.

Sage is such a wonderfully perfect software that all we have to do now is discuss the use of sqcup and cup. Everything else has been solved.

The documentation is much better in is_transversal_design because of the NOTE block. But there is nothing in transversal_design. Could you do a copy/paste or something.

(For me, it would be clearer for a TD to be a subset of V1 x V2 x ... x Vk but let us stick to conventions).

That's precisely why we have both TD and OA. Because you can easily intersect the sets of a TD, but you cannot intersect elements of V1 x V2 x ... x Vk.

Nathann

comment:36 Changed 5 years ago by git

  • Commit changed from 8273741e4f9cd86c788e2769084c954c24b1c8cf to a86b08e5a2a8f21fe20b272ebf4c2734f315b231

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

a86b08etrac #15431: Mention that we assume \lambda=1

comment:37 in reply to: ↑ 35 Changed 5 years ago by vdelecroix

  • Keywords designs added
  • Reviewers set to Vincent Delecroix
  • Status changed from needs_review to positive_review

Ok. This is good enough for me.

comment:38 Changed 5 years ago by ncohen

(despite our arguments :-P)

Thaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaanks !

Nathann

comment:39 Changed 5 years ago by vbraun

  • Branch changed from u/ncohen/15431 to a86b08e5a2a8f21fe20b272ebf4c2734f315b231
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:40 Changed 5 years ago by ncohen

  • Commit a86b08e5a2a8f21fe20b272ebf4c2734f315b231 deleted

Updates:

The product construction is now available in #16227

The equivalence between OA/TD/MOLS is now available in #16231

Nathann

Note: See TracTickets for help on using tickets.