Florent Hivert wrote: >>> One thing that I thought was very interesting was their way of allowing >>> for custom inline operators in python. It inspired the following >>> @inline_operator decorator. Would this be useful in Sage? >>> >>> class inline_operator: >>> def __init__(self, function): >>> self.function = function >>> self.left = None >>> self.right = None >>> >>> def __rmul__(self, left): >>> if self.right is None: >>> self.left = left >>> return self >>> else: >>> right = self.right >>> self.right = None >>> return self.function(left, right) >>> >>> def __mul__(self, right): >>> if self.left is None: >>> self.right = right >>> return self >>> else: >>> left = self.left >>> self.left = None >>> return self.function(left, right) >>> >>> >>> # EXAMPLE >>> >>> a=[1,2,3] >>> b=[3,4,5] >>> >>> # This emul operator returns the element-wise product of two lists... >>> @inline_operator >>> def emul(a,b): >>> return [i*j for i,j in zip(a,b)] >>> >>> # Returns [3,8,15] >>> a *emul* b > > +1 for integrating this in sage. One very common application: > > a *tensor* b *tensor* c > > If it's doable to extend the BackslashOperator trick to allows for the user to > define his new operator without changing the performance, I'd like to advocate > for it. My feeling that by default, we should stick to python syntax. Indeed, > we don't want the user which learn sage to learn a different syntax. Moreover > as burcin pointed out on irc, if we allows for to much different syntax, it > might be hard to transfer code around.
Yep, I totally agree. > > On the other hand, good mathematics relies heavily on good notations. And this > is particularly true in combinatorics. So that, in my opinion we should allows > the user to define new operators. Maybe with the intend to keep the use of > those notations at the interractive level. Yep, that's what I was intending. We could have a predefined set of operators that the user could import into the global namespace to give some sort of "blessed" syntax for interactive use. For example, there are lots of different kinds of graph products for which having infix notation would be very convenient. > > Here is an example of usage: I'm working on a particular class of algebras > called dendriform algebras. Here the product * is decomposed as the sum of two > operations say >> and <<: > a * b = a << b + a >> b > > The operations >> and >> are some action of the algebra over itself, they > verify some relations such as > (a << b) << c = a << (b * c) > (a * b) >> c = a >> (b >> c) > > I can't imagine working in this without using a good *infix* notation. For Yes, thanks. For some reason, I was drawing a blank when trying to remember the word "infix". The subject should have read "Custom infix operators in python". > this particular case I can *abuse* __lshift__ but I'd rather being able to > define new notations. I'd like to extend the above decorator to handle several different common precedence levels, maybe just addition, multiplication, and power. Thanks, Jason --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
