On Sunday, November 10, 2013 10:42:39 PM UTC+1, Joachim Durchholz wrote:
> Hm. Not a problem if the same function isn't overridden in both Expr and > AssocOp, so maybe... hopefully... > > ... but yes, that's going to have to be considered for multiple dispatch. > I was thinking about that. That AssocOp is interesting, it defines the commutative property of Add. The fact is, the Add object has two logical meanings: - represent the plus "+" sign - encode the properties of the addition Actually, the properties of the addition can vary according to what objects are inside of Add. If you have just numbers, then you get a number, with symbols you get a summation of symbols, with infinities an complex numbers, more complex behavior. In other parts of SymPy there are MatAdd, TensAdd to represent additions of matrices, tensors, etc..., which have their own properties. Developer deemed that it would be too complicated to add rules to Add, so they wrote other Add-like objects. In other cases, like the aforementioned infinities, Add is still kept, by adding behavioural rules to it. But, isn't this breaking the logical correspondence of those two points in the bullet list? The plus sign is no more mapped to a single object, while the properties of addition are sometimes handled by Add, sometimes by other objects. What about using instead of this an approach closer to C++ templates? I mean, the Add class would always represent a plus sign, for every expression, while its properties are managed by templates, so, keeping a C++ syntax: - Add<AssocOpT> ordinary - Add<InfinitiesT> for additions containing infinities. - Add<MatrixT> for additions containing matrices. - Add<NonCommutativeT> for additions containing non-commutative symbols. - Add<NonCommutativeInfinitieT> for both inf and non-commutative symbols. - Add<QuantumExpressionT> for the case mentioned by Brian, thus avoiding usage of pattern matching. In this case, the properties and behaviour of the arguments of Add are managed by special classes. The point is, the addition of new objects to an Add argument list, could change the template of the resulting new Add, e.g. Add(x, y) ==> Add<AssocOpT>(x, y), while Add(x, y) + oo ==> Add<InfinitiesT>(x, y, oo). At this point, multiple dispatch could be defined so as to keep templates in regard, but I'm still unsure how this could work, but I made up my mind to post this anyway. I'm not even sure that properties should be regarded as templates, but, in any case, using such an external marker given immediately information about special symbols inside Add. So, in quantum mechanics, the exp( ) function could immediately catch that its Mul/Add content contains quantum mechanical operators, thus acting appropriately. -- You received this message because you are subscribed to the Google Groups "sympy" 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/sympy. For more options, visit https://groups.google.com/groups/opt_out.
