#15278: Hash and equality for graphs
-------------------------------------+-------------------------------------
       Reporter:  SimonKing          |        Owner:
           Type:  defect             |       Status:  new
       Priority:  major              |    Milestone:  sage-5.13
      Component:  graph theory       |   Resolution:
       Keywords:                     |    Merged in:
        Authors:  Simon King         |    Reviewers:
Report Upstream:  N/A                |  Work issues:
         Branch:                     |       Commit:
  u/SimonKing/ticket/15278           |  c774057bf07b2da8539f2395555b2062428874f4
   Dependencies:  #12601             |     Stopgaps:
-------------------------------------+-------------------------------------

Comment (by ncohen):

 * About not requiring `allows_multiple_edges` and `allows_loops` to be
 equal :
   there is actually a technical problem there I just noticed : the
   `get_edge_label` function behaves differently according to the value of
   `allow_multiple_edges()`. It returns either a label, or a list of
 labels. And
   that complicates things.

   {{{
   sage: g = graphs.PetersenGraph()
   sage: print g.edge_label(0,1)
   None
   sage: g.allow_multiple_edges(True)
   sage: print g.edge_label(0,1)
   [None]
   }}}

   (I hate labels and multiple edges)

   Besides, testing whether the graph containts multiple edges is currently
 a bit
   costly. I think we actually go over all edges, and test it.

 * About `.weighted()` : looks like the meaning of "weighted" is only used
 in
   `spanning_tree.pyx`. And I'd say that this can easily be replaced by an
   additional argument to the methods (as it is already the case in many
 others,
   like `flow` of `traveling_salesman_problem`)

 * I believe (note sure, never used it) that `.weighted()` only indicates
 whether
   the labels on the edges are to be understood as weights. That's all.
 Multiple
   edges are handled by the backend, and each edge can have a different
 label,
   it's unrelated.

 * I don't see any problem with using #12601. Do you see one ?

 * `copy(gi)` takes a lot of time : indeed, returning `self` makes sense.
 If one
   actually wants to copy the immutable copy of the graph, i.e. the
 underlying C
   data and arrays, this can be made MUCH faster than the current
   implementation. Two calls to `memcpy` and it's settled `:-P`

 * Why didn't you use the decorators from your first immutable graph patch
 to
   deal with immutability in `.weighted()` ?

 * If you want to check that current functions act well on immutable
 graphs, you
   may be interested by the decorator named `_run_it_on_static_instead` in
   `sage.graphs.backends.static_sparse_backend`. It makes the function take
 the
   graph as input, create an immutable copy of it, and run the code and the
   immutable copy instead. It's still a lot of manual work to do, but it's
 easier
   than trying the functions hand by hand. Just add the decorator to the
 graph
   functions you want to test, and run the doctests `;-)`

 Sorry for the delay. I moved a lot through Paris with my backpack during
 the
 last days `:-P`

 Nathann

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

Reply via email to