#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 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
--
Ticket URL: <http://trac.sagemath.org/ticket/15431#comment:28>
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.
