#19221: Some new (n,2^k,1)-BIBD
-------------------------------------------------+-------------------------
Reporter: ncohen | Owner:
Type: enhancement | Status:
Priority: major | needs_info
Component: combinatorial designs | Milestone: sage-6.9
Keywords: | Resolution:
Authors: Nathann Cohen | Merged in:
Report Upstream: N/A | Reviewers: Vincent
Branch: | Delecroix
78d008dce6ad2f415dc703861b529f6fa0e95841 | Work issues:
Dependencies: | Commit:
| Stopgaps:
-------------------------------------------------+-------------------------
Comment (by dimpase):
Replying to [comment:15 ncohen]:
> > hmm, I have done an analogous change to !ProjectiveGeometryDesign in
#19226, but I called coordinates "coordinates", not "labels", and I have
chosen no coordinates as the default. How about we unify this?
>
>
> 1) 'labels' occurs is many Sage methods, and so I chose this term as
users will after a time 'get used' to it. 'coordinates' is also meaningful
in the context of projective planes, but will not be meaningful for all
functions that [will/will not] add labels. And I would like to avoid this:
but `labels` are meant to be user-defineable. Calling a set of labels
chosen by the implementation `labels` is unhelpful and uninformative, to
say the least.
>
`Graph.is_tree(certificate=True),is_prime(get_data=True),Graph.is_strongly_regular(parameters=True),IncidenceStructrure.is_t_design(return_parameters=True)`.
In terms of interface, I think that 'certificate' everywhere would have
been better.
>
> For the choice of coordinates, I made the usual choice: from most user-
friendly to least user-friendly. Like we have a 'check' argument (enabled
by default) that can be diabled if needed, like `Graph.edges()` returns
edge labels are `Graph.edges(labels=False)` does not.
>
> > I also do not understand how an invasive change of changing the
behaviour to use by default coordinates for the
!DesarguesianProjectivePlaneDesign was done without an appropriate
deprecation...
>
> Because it apparently does not break anything that was claimed
previously by its documentation. Also, because it is clearly an
improvement.
well, as you know, even Sage library code used the implementation's
labellings in some
places, instead of doing this via ground_set()...
>
> > I also don't understand why there is a separate implementation of
DesarguesianProjectivePlaneDesign(q), which can be replaced by
ProjectiveGeometryDesign(2,1,q). How about just making
DesarguesianProjectivePlaneDesign into an alias to the latter?
>
> If I remember correctly, the explanation to that lies in the running
times.
Indeed, it's 50 times faster on PG(2,16). I wonder why...
--
Ticket URL: <http://trac.sagemath.org/ticket/19221#comment:24>
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.