Robert Miller wrote: >> 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) >> >> 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? > > This is false. The union function returns a new graph, so the first > method already works.
Yes, it currently does this; good point, I should have mentioned that that was how it was currently programmed (did I not? Sorry). I was proposing a different design. My whole inquiry has to do with what "should" (for a suitably defined should :) the interface be and are there official guidelines (or should there be official guidelines) for this type of operation on an object so that there is consistency across SAGE. I think the overall answer that I'm getting is that things (mathematical objects) should generally be considered immutable unless it really doesn't make sense or is very inconvenient to consider them immutable. We can later use ref-counting tricks to cut down on the resulting overhead, so don't worry too much about it. I think that that sounds like a great convention. 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/ -~----------~----~----~----~------~----~------~--~---
