#18972: twographs and Seidel switching
-------------------------------------+-------------------------------------
Reporter: dimpase | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.9
Component: graph theory | Resolution:
Keywords: | Merged in:
Authors: | Reviewers: Nathann Cohen
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/dimpase/seidelsw | 2fae2fc7b92d306f1336b6786c67318823f812f4
Dependencies: #18960, #18948, | Stopgaps:
#18988, #18991, #18986, #19018, |
#19019 |
-------------------------------------+-------------------------------------
Comment (by dimpase):
Replying to [comment:66 ncohen]:
> > Well, I am using 'has_edge' there now, which you say is fast. So the
bottleneck of creating neighbour lists is gone, no?
>
> No, it is not gone. There is a huge loss of time in this function
because you want to build it from a lambda function.
We already discussed here a similar issue and found that we talk about
5-10% loss (which can hardly be called huge) no?
Perhaps making `Nv` and `NoNv` (frozen)sets will be an extra optimisation
that I am willing to add, but other than that it's matter of taste,
IMHO...
>
> > Mind you, you said in comment 1 above that I should move these things
to graph.py.
>
> What I meant is that `DiGraph.twograph()` should not exist. Surely you
agree with that?
Look, I read what you wrote, and you wrote the following:
{{{
3) If your methods only apply to undirected graphs, they should be in
graph.py
}}}
And I duly put the stuff into graph.py.
>
> > And it's not much code being added, compared to complicated algorithms
not in Graph that you mention.
> > Anyway, we should open another ticket to reorganise the Graph module.
I agree that Graph has a lot of methods, and they should be better
organised.
>
> Could we please keep it out for the moment? It is not for the code that
I advocate this, it is merely for the length of the list of functions that
appears to the user.
No, why should we keep this out now? I hope you don't like the role of the
code bouncer you play now... The methods need to be cathegorised better,
that's all.
Dumping too much stuff directly into g.TAB (for g a Graph) is bound to
cause a problem sooner or later.
Presently I find it absurd that we have e.g.
`kirchhoff_symanzik_polynomial` but we cannot have `twograph_descendant`.
Certainly there should be g.polynomial.TAB,
g.graph.TAB, g.decomposition.TAB, g.matrix.TAB etc etc.
>
> I don't mind improvng the `twograph_descendant` myself if that can ease
the deal.
Sure, please.
--
Ticket URL: <http://trac.sagemath.org/ticket/18972#comment:67>
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.
