On Sep 26, 2007, at 8:59 PM, Jason Grout wrote: > Robert Bradshaw wrote: >> The sage coercion model guarantees that when x.__add__(y) is called >> (well, technically x._add_ or x._add_c_impl), the argument y is of >> the same type and parent as x. For example >> >> sage: R.<x> = ZZ[] >> sage: x+1/2 >> x + 1/2 >> sage: parent(x) >> Univariate Polynomial Ring in x over Integer Ring >> sage: parent(1/2) >> Rational Field >> sage: parent(x+1/2) >> Univariate Polynomial Ring in x over Rational Field >> >> In your case, someone could type >> >> sage: g = CompleteGraph(5) >> sage: g+1 # will call g.__add__(1) >> ??? >> >> which you have to deal with. Typically, just throw an error if it's >> not a graph. But what about graph + digraph? Digraph + digraph? Etc. >> Should graph + x be a new graph with a new (unconnected) vertex 'x'? > > Thanks for the explanation of the coercion model. That is a very nice > way to do things.
It's the product of a lot of work by a lot of people. > As for graphs, there isn't a standard definition for the "+" operation > that is agreed upon, even for graphs of the same type (e.g., should it > be disjoint union or union?). That's why I was asking about custom > infix operators, so I could make a disjoint_union infix operator, > which > was clearly different than the union operator, which was clearly > different than whatever else. Another reason for custom infix > operators > was to allow for all sorts of different kinds of products (just > look at > the Graph class to see many examples), any of which could be > represented > as "graph * graph". The same issue came up with vector * vector. It used to be pairwise product, but most people expected dot product, so that was changed. In any case, the old operations should probably be left as methods and __add__ would dispatch to one of them. I think (normal) union is the best way to define it, as graphs are like sets + edges, and for sets + does the normal union thing. I don't think there's a way to make new infix operators, and am not sure that is a good idea anyway. The logic operators of __or__ and __and__ might make sense for union and intersection though. > The best I've come up with at this point is, given graphs > A,B,C,D,E, the > union is: > > A.union(B).union(C).union(D).union(E) I actually think that this looks very clear, despite the lack of infix operators. > where the union function returns the modified graph each time so I can > keep chaining union function calls. The union actually modifies the > graph A, so if you want A left alone and a new graph returned, you do: > > newgraph=A.copy().union(B).union(C).union(D).union(E) > > Comments? Is there a better way to do things? I would rather union returns a new object rather than modifying A, it's much easier to reason about code that way, and fits better with the rest of SAGE. One could provide a different method to do union in place if one needs. > With time, I suppose the graph theory community will settle on a > commonly accepted meaning for "graph + graph", but as far as I > understand, that hasn't happened yet. > > Thanks, > > -Jason > > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
