I think you've hit on the core of the issue. The problem is, if you
take just Symbol('x'), it can be interpreted as many things. x + 1
means the number x plus the number 1 (or does it mean the function
f(x) = x + 1?). x + O(x**2) means the set of functions whose series
expansion up to x is x. x + y could mean that we think of x and y as
matrices of the same shape.The thing that really has bothered me is that it's hard to state clearly, what exactly should be a subclass of Expr. The best definition I've come up with is, "those things that make sense with Add and Mul". I can tell you what's *not* Expr. Tuple is not Expr. Boolean expressions (anything that can be thought of as having a truth value) are not Expr. Mathematically, + has a thousand meanings, and we blur the distinctions because they all act similarly. But at some point in a CAS, you have to unblur any notational convenience that you would otherwise make on paper. Aaron Meurer On Sun, Nov 10, 2013 at 3:21 PM, F. B. <[email protected]> wrote: > > > 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. -- 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.
