#15431: Transversal Design TD(6,12)
-------------------------+-------------------------------------------------
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: | a537755ebc4522efd30c12c9225abfcac1d36a90
Nathann Cohen | Stopgaps:
Report Upstream: N/A |
Branch: |
u/ncohen/15431 |
Dependencies: |
#15287 #15368 |
-------------------------+-------------------------------------------------
Comment (by vdelecroix):
Hello Nathann,
Replying to [comment:26 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
--
Ticket URL: <http://trac.sagemath.org/ticket/15431#comment:27>
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.
