#16598: Useless new classes and a replacement for _check_pbd
-------------------------------------+-------------------------------------
Reporter: ncohen | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.3
Component: combinatorial | Resolution:
designs | Merged in:
Keywords: | Reviewers:
Authors: Nathann Cohen | Work issues:
Report Upstream: N/A | Commit:
Branch: u/ncohen/16598 | 3f8cebb0d68d7e7ae0e9c763e9bc78a1bdb847dd
Dependencies: #16553 | Stopgaps:
-------------------------------------+-------------------------------------
Changes (by ncohen):
* status: needs_info => needs_review
Comment:
Hello !
> I got it for the automorphism group! Thanks. But your definition of gdd
is wrong:
Ahahahahah. Well, that's what I intended, but... is the new version
clearer ?
> What do you think of having only one class (with blocks and groups) and
methods:
> - `.is_t_design(self,t,v,k,l)`
> - `.is_group_divisible_design(self,v,G,K,l)`
> - `.is_partially_balanced_design(self,v,K,l)`
How would you call the class ? If you want to have these functions as
methods of something, the only choice I see is `IncidenceStructure`. We
would have no `.groups()` method but those functions could get the groups
as an argument.
> I do not like the fact of having one extra empty class whose only
purpose is a check at creation...
I just created GDD because it was the common generalization of `TD` and
`PBD`. Mostly for the doc at the moment, and we will have some place to
put code that works on groups.
> Moreover, if we switch to mutable classes it would be cool that after
transformations we check the kind of thing we obtain.
Hmmmm... I don't expect that GDD or anything that inherits from it will
ever be mutable. `IncidenceStructure` could be mutable someday, though. It
wouldn't be cool to have a GDD object which is not a GDD. Plus as you
noticed, most of these objects are created from others, rarely modified
inplace.
> The only thing that bother me a little bit is this `dual` method which
does not make any sense for groups (perhaps it does??).
Well, it just does not consider them. To me those "groups" are a parameter
of the design, nothing else... The dual of a dual of a GDD is a GDD, so
everything is cool. The blocks are forgotten (they can be re-computed
automatically anyway), but who cares ? I don't think that you would find
any other definition of the dual of a GDD anywhere...
> Why do you not translate the groups over integers as it is the case for
blocks?
Oh. I thought that I would only define GDD for integer ground set, but
indeed it also handles the non-integer case almost for free as we know
that "._blocks" are already translated to integers. You are right. I will
updated that in a second.
> You really like to use tuple of tuples for groups and list of lists for
blocks (see comment:4 above)?
I don't understand. `.groups()` returns lists at the moment (before my
commit)
{{{
def groups(self):
return map(list,self._groups)
}}}
Oh, I see ! You meant for internal storage ! Fixed in the new commit.
Nathann
P.S. : While writing the commit, I made !IncidenceStructure mutable. But
it's not reaaaaaaaaaaallly a problem, it preserves all the structure !
`:-D`
--
Ticket URL: <http://trac.sagemath.org/ticket/16598#comment:11>
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.
