#16553: Clean IncidenceStructure
-------------------------------------------------+-------------------------
Reporter: vdelecroix | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: sage-6.3
Component: combinatorial designs | Resolution:
Keywords: | Merged in:
Authors: Nathann Cohen, Vincent | Reviewers:
Delecroix | Work issues:
Report Upstream: N/A | Commit:
Branch: | Stopgaps:
Dependencies: |
-------------------------------------------------+-------------------------
Comment (by vdelecroix):
Replying to [comment:2 ncohen]:
> Yo !
>
> > - I think we also want another bijection `blocks <-> {0, ..., b-1}` to
have well defined incidence matrices. It would also help to choose proper
labels for the dual incidence structure.
>
> Well, the points of the dual incidence structure could be ... Sets ?..
Or tuples. I mean, the labels of the points of a dual incidence structure
could be the blocks of the original incidence structure.
> ANd of course, the blocks would be .. Sets of points from the ground set
?
This is confusing. Basically, we do not care too much about the data type
of the blocks as soon as `__len__`, `__iter__` and `__contains__` are
correctly implemented, right... But it does not work with dual.
One option is to do like posets where the ordering is implemented in the
Poset itself and not in the elements. We would implement the incidence
structure at the level of IncidenceStructure and not at the level of
points/blocks. In other words we would forbid `p in block`.
>
> > - A better name for `IncidenceStructure` would be `Design`...
>
> Or hypergraph ?... A friend of mine says "geometry" instead of
"hypergraph". Truth it, an incidence structure is a pretty general thing :
>
> http://en.wikipedia.org/wiki/Incidence_structure
>
Yes, we need `Hypergraph.to_incidence_structure` and
`IncidenceStructure.to_hypergraph`... or only one class?
> > and we also need a class for `GroupDivisibleDesign` and for them we
need an other bijection `groups <-> {0, ..., g-1}`.
>
> Well, we may need to have ".groups()" indeed. We would have GDD at the
bottom, them PBD, BIBD, transversal designs...
>
> The main problem is that orthogonal arrays are not really designs in
this sense.
>
> > - to fit with enumerated set the natural terminology for the bijection
would be `rank/unrank`
> > {{{
> > class Design:
> > def rank_point(self, point): # index of ``point``
> > def unrank_point(self, n): # ``n``-th point
> > def rank_block(self, block): # index of ``block``
> > def unrank_block(self, n): # ``n``-th block
> > }}}
>
> Really ? Ewww.. Honestly I'd be glad to avoid things like that and keep
the integer names internal. Users do not need to see that !
All right.
Vincent
--
Ticket URL: <http://trac.sagemath.org/ticket/16553#comment:3>
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.
