Helloooooooooooo !! > It's not the easiest to document, though.
Really ? I was thinking of : - ``tried`` -- Internal use. Keep your fingers off. > It seems that the answer you get > back depends on which construction you use, given your parameters. Yes, but it does not matter much. The function is supposed to return a design corresponding to the parameters, without any other claim. Knowing that it exists is cool already, having one is even better. The answer will probably change over time though, if we end up adding more general constructions, or just add new ones that overlap with others. > Can you > easily untangle the relations between your mutually-calling-each other > routines and document, given the routine called and the parameter used, > which answer you get back? Not really. To build a TD(k,n) you will need a TD(k', n'), possibly several of them. If there is a TD-specific construction for TD(k,n) it will require smaller TD objects, and there may not be any TD-specific constructions for those smaller TD objects, hence you call for help and perhaps OA or MOLS will answer it. It's a gigantic mess, and perhaps you can get an idea by looking at this theorem (see picture, corresponding to #15310). There are some constructions of TD from smaller ones, some infinite families... There is even one I need for a bigger construction which I implemented for specific values ! (see #15431). > Can you make sure that the answer returned is > robust in the face of subtle call changes? I can't. But anyway the users are supposed to ignore this "tried" parameter. It is just there to implement this "if and only if", and that will be in the three main functions only. > While your theorem says the existence of the different structures is > equivalent, the need to implement different constructions indicates that > your constructions aren't. Indeed. It's sometimes easier to see the same object in "this" way rather than "that" way. > Reflect that in your code. If your constructions > complement each other sufficiently, there is now a theorem left to prove > that TD(k,n) will return a structure if it exists for that choice of > parameters. If you don't prove that theorem, you should obviously not call > the routine simply "TD" but something more cautious, such as > "try_a_lot_of_things_to_construct_this_TD". I don't get it. There are some families of parameters for which we know that the parameters exist. For some other values, the designs exist because the values k,n can be decomposed following Wilson's theorem or others into smaller designs that do exist, because they can be decomposed too, .... This part of mathematic is a gigantic mess. Don't overestimate what is know about that. Just to give you an idea, take a look at that : http://goo.gl/YTFPwl That's how bad we are. We have tables of known values :-P Having for constructions of such things instead of these tables would be good. Having better constructions than what this book claims would be something we could boast about. Though there is no chance that I'll ever check :-PPPPPPPP Nathann -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
<<attachment: wilson.jpg>>
