#14535: Mutability of Graphs
------------------------------------+---------------------------------------
Reporter: SimonKing | Owner: jason, ncohen, rlm
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-5.10
Component: graph theory | Resolution:
Keywords: mutability graph | Work issues:
Report Upstream: N/A | Reviewers:
Authors: Simon King | Merged in:
Dependencies: #14524 | Stopgaps:
------------------------------------+---------------------------------------
Comment (by ncohen):
Hellooooooooooooooo !!!
> There certainly is a slowdown in all methods that are protected in this
way. And I do not use the decorator in cdef classes, in an attempt to
prevent a regression.
Hmmmm. And why should we accept a 10% slowdown in order to have immutable
graphs ? `:-P`
> Does it make sense to time methods like add_vertex separately? In my
applications, one would build a graph, and then it will never again be
changed. But I am sure you have better use cases than I. Do you have
examples in which add/delete_vertex/edge will typically be called zillions
of times?
Not really. Like you, in my examples I spend most of my time reading
graphs. And wasting my time translating labels into integers `:-P`
> > * Besides, why do you need decorators in the Python classes if you
forbid modifications directly in the backend ?
>
> I do not forbid to change the graphs in the backend. Or at least, I did
not intend to modify the backends. If I did, then it was by mistake. If G
is an immutable graph, then `G._backend.add_vertex(...)` should not
complain.
? But you make changes to `CGraph`, `SparseGraph` and `DenseGraph`, don't
you ? `O_o`
And why wouldn't it be better to only deal with immutability directly in
the backends ? No need for decorators if it is done there, and if it is
only a "if" with a niiice C variable which never changes. Would reduce the
slowdown, wouldn't it ?
> The reason is, again, that I don't want a slow-down in the "private"
methods. If one has an immutable graph used as key in a dictionary, and
then decides to work around the "protected" methods `add_vertex`,
`add_edge` etc by changing the graph G via G._backend, then this is a
conscious decision for which the user takes full responsibility.
Hmmmm... But the developpers could have to do that to make some methods
more efficient, and then we would have to deal with immutability by hand.
But really I am interested in your answer : why don't you prefer to deal
with immutability in the backends directly ? In the `graphs/base/` files ?
> > * You create 4 functions in a class that already has a LOT of them. We
have several functions that work like that already :
> > {{{
> > sage: g.mutable()
> > Tells you if it is mutable
> > sage: g.mutable(True)
> > Sets it to be mutable
> > }}}
>
> I did not find any support for mutability in graphs, except for the hack
that makes `hash` work.
Nonono, we don't have such a method at all ! But we have two methods to
allow loops and test if they are allowed :
{{{
sage: g = graphs.PetersenGraph()
sage: g.allows_loops()
False
sage: g.allow_loops(True)
sage: g.allows_multiple_edges()
False
sage: g.allow_multiple_edges(True)
}}}
So it's already half of what you take, and we could even merge two
functions like `allows_loops` and `allow_loops` into one, as in my
previous example. That's one of the joys of coding in Python.
> Actually, when I created the ticket, I first looked at a preview, and
saw that you are among the (default) owners of this ticket. Hence, I
concluded that there is no need in adding you in Cc, because you already
were on the list of recipients. Sorry if I misinterpreted the meaning of
the list of "owners".
Oh. I see. Then it's the Trac developper's fault. The owners of a section
are expected to receive an email indeed, except when there are ... several
owners.
In that case, no mails are sent `:-P`
http://trac.edgewall.org/ticket/7793
Nathann
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14535#comment:8>
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
