> Symbol is perfectly consistent with sympy's existing object model. Since > it's an Atom, it doesn't have args and is free to use whatever > attributes it needs. > > OTOH, what MatrixSymbol does is wrong and unsupported. Being an Atom and > having args is inconsistent and causes problems for algorithms that > don't expect it, eg.:
If it is still unclear, I am not stating that everything is ok as it is. I am asking how to solve issues raised by objects like MatrixSymbol. Just stating that it is not working with current algorithms is not of much help. >> So basically my question is. what do you prefer. Hacks like what is >> done to the name string of Symbol or permitting non-Basic objects in >> the args of the leafs of the sympy expression tree. Basically, the >> presence of non-Basic objects in the args will be what defines the end >> of the recursion. > > By definition, a leaf can't have args, so I don't understand what you > mean. If you're saying that leaves should be either Atoms or non-Basic > objects, that's de facto the way it works now, though making it the rule > would contradict issue 2070 and test_args.py. Well, this definition does not work well **in practice** at the moment. This is why I am asking how to fix it. If neither using Symbol for strings (hackish) nor redefining what an atom is (takes long time, requires fixing many tree traversal routines) is a viable route forward there must be another way. I do not think that just stating "MatrixSymbols (or something similar) has unexpected args" is of any help. No one has proposed a clear solution that will work with "named object that must have args" different from the two that have been proposed above. So the way forward is to choose between (I may be missing alternative options): - say that sympy will never support "named objects that must have args" - use Symbol when we need name strings - redefine what an atom is and correct each failing algorithm one by one The first one is just giving up on implementing something that is obviously useful. The second one is hackish. The third one is hard. However it would permit to refactor all three traversal algorithms in a better abstracted way. Yes, it does contradict issue 2070, but the only reason that this issue exists is that the current methods for three traversal are limited (I may be wrong about this, however I have asked the question many times and I have never received a different answer.) -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
