#14535: Mutability of Graphs
------------------------------------+---------------------------------------
Reporter: SimonKing | Owner: jason, ncohen, rlm
Type: enhancement | Status: needs_info
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 SimonKing):
Hi!
Replying to [comment:2 ncohen]:
> Hello !
>
> * Could you show that there is no slowdown in the graph functions
because of that please ?
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.
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?
> * 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.
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.
So, protection of the user will be restricted to the "official" methods
G.add_vertex etc.
> * 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.
> * There is a lot of things that graphs store and which are not vertices,
nor edges. For example the vertices' layout, or its name... You can see
the list of these awful things in `GenericGraph.__eq__`. If you just want
to take edges and vertices in consideration could you say it explicitely
in the documentation of the `*_mutable` methods ?
Not good. Yes, I should have looked up `GenericGraph.__eq__` and take into
account all data used there.
> And.. Well.. Could you add me in Cc when you write things like that ?
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".
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14535#comment:4>
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.
