Robert Bradshaw wrote: > On Sep 26, 2007, at 8:59 PM, Jason Grout wrote: > >> 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.
I guess this illustrates the problem of only having a few basic symbols that we can overload. On the other hand, simplicity results as well since there isn't new notation for every different kind of object. On the third hand, though, it makes translating math into python harder, since we do use all sorts of different notation in math. That's one reason why the interface to Mathematica is nice---most any math (unicode?) symbol can be assigned to a function and given mathematical meaning. >> 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. That's why I finally settled on it. > >> 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. I guess this brings up a much more general issue of conventions in SAGE (in general, should methods modify an object in-place or pass back a new object?). I'll post up a new thread to try to clarify and get feedback on what conventions there are/should be. Thanks for everyone's feedback! -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/ -~----------~----~----~----~------~----~------~--~---
