#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 SimonKing):

 Replying to [comment:8 ncohen]:
 > > 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`

 It would be nice to have a better solution, but, as for matrices, I do
 think it would be good to be able to use graphs as keys in dictionaries
 ''without'' a hack.

 > > 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`

 Then we may have different notions of "backend". By "backend", I
 understood the stuff that is assigned to `G._backend` and is defined in
 sage.graphs.base.graph_backends`.

 You think it might be better to move all mutability checks into the
 backend? I thought so as well, initially. But then I found that a couple
 of add_* methods first change some data ''outside'' of the backend, and
 call the backend method only later. So, I thought it is safer to check
 mutability not in the backend, but in the graph.


 > 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 ?

 I would prefer to deal with it in the backends.

-- 
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14535#comment:9>
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.


Reply via email to