#14980: graph_generators, some more clean up
--------------------------------+---------------------------
Reporter: eisermbi | Owner:
Type: enhancement | Status: needs_info
Priority: major | Milestone: sage-5.12
Component: graph theory | Resolution:
Keywords: | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Dependencies:
Stopgaps: |
--------------------------------+---------------------------
Changes (by ncohen):
* status: needs_review => needs_info
Comment:
Helloooooooooooooooooooo !!!
If I remember correctly, this "small graph" has also been called "named
graphs" or "unique graphs" through time, none of which was satisfying.
Because some named graphs are actually families, because "unique" has a
mathematical meaning too... But it was meant to indicate that the
constructor takes no parameter, indeed. "small" here means "bounded-size",
I guess `:-)`
To me complete graphs should belong to the basic structures, Petersen not.
Well, that's just my opinion on the matter.
Part 1:
It all makes sense to me. Individual graphs is a nice name too, btw. This
being said, do these names really appear in Sage ? That's the module's
name of course but users get those graphs through `graphs.<tab>`, so it's
not that bad either. Not that it shouln't be changed if you think it's
wrong of course.
Part 2:
- Why did you remove the index in chessboard.py ? An index is
niiiiiiiiiice `:-P`
Plus this module will not change much, so it's not very hard to keep
updated.
- You changed the order of methods in the Platonic Solids, but the
`append_to_doc` method reorders them according to the alphabetical order
`:-P`
- What do you mean by "chessboard graphs are now a subsection of families"
?
- Bad formatting of Random GNP : could you open a ticket for that and add
me in cc ?
Part 3:
- Why on earth wouldn't `fullerenes`, `trees`,
`line_graph_forbidden_subgraphs` and `cospectral_graphs` be families of
graphs ? `O_O`
- If these are not moves to `miscellaneous.py`, this module doesn't have
any meaning if it just contains the world map. Actually, I created an
independent file for this graph because it takes sooooooooooo much Python
code to build.
Part 4:
Wow. This patch is a bit hard to read.
First, it seems from your message that after this patch is applied some
method may be defined in two files, and we just don't do that. We'd be
sure to fix a bug in one without fixing the other. Unless you imported one
into the other file, in which case my reason for opposing this change is
different :
First, I don't get your main argument : how can moving methods around in
these files change anything for the users, when he can get them all
through `graphs.<something>` ? These constructors have only been split
because Jeroen didn't want the `graph_generators` file to grow too large,
and the users do not even have to know that they exist. Is it just because
of the index in `graph_generators.py` ?
Overall:
- You fixed typoes in `sage.graphs.graph_generators` in some places, but
could you change it to {{{:mod:`sage.graphs.graph_generators`}}} instead ?
So far I agree with the first 3 parts, short of this question of things
which you don't think are graph families. Tell me what you think ! `;-)`
Nathann
--
Ticket URL: <http://trac.sagemath.org/ticket/14980#comment:2>
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/groups/opt_out.
