Considering the merge of the quantum branch and some of the recent discussions, I have a few ideas to make sympy more modular and to make it easier to extend it.
Mathematical types ------------------ While the concept of type doesn't usually appear explicitly in elementary presentations of mathematics, it's very important for mathematical intuition, allowing for instance to recognize immediately that it's absurd to add a scalar and a vector. So, every sympy object should have a 'type' attribute (NB: this is independent from the class of the object returned by 'type(obj)'). These types should be sympy objects themselves, forming a hierarchy - a directed acyclic graph - similar to a class hierarchy, including equivalents of isinstance and issubclass. Also, each type defines a Python-level interface (implemented as a mixin or abstract base class) which objects belonging to that type must implement (e.g. by subclassing the interface). This allows the decoupling of the mathematical properties from the implementation and, provided that algorithms use only the interface instead of details of the actual class, should allow different implementations of the same type to coexist without troubles. Now, what prevents these types from simply being implemented as ABCs is that we need parametric types (like Vector(Real, 3)) and that we want operation objects like Add to have different types depending on their arguments so that Int + Real -> Real, Ket + Ket -> Ket and Ket + Real -> TypeError(?). Implementing these objects with covariant type is, of course, is the tricky bit, but it would allow to extend sympy without having to reimplement half the core's classes. Another benefit of this is that we could implement a Variable class so that implementing a type would automatically allow us to create symbolic instantiations of it. Which brings me to my second point... Symbols vs variables -------------------- Currently in sympy, there is no distinction between the concepts of symbol and variable. Yet these are different. A symbol is just a sign - blobs of ink on the page - without any intrinsic meaning. A variable is basically a placeholder that can be replaced by any value in some range. The properties of the variable are the properties that are common to all the elements of the range. Most of what we do in sympy should use variables, symbols should only matter for parsing and printing. Symbol() objects are actually almost variables already. Besides the name, they only lack a more explicit range and shouldn't require a name. Intermediate representation for printing ---------------------------------------- At the moment, we have many different printers (str, repr, pretty, latex, mathml, ...) and printing logic specific to an object needs to be implemented for each of them even though we want the results to look similar between most printers. It would be much easier if we could specify once how the object should be printed (e.g "put the contents of self.label between a vertical bar and an angled bracket") and let sympy take care of outputting actual LaTeX/MathML/pretty-printer stuff/... So, the idea would be to have a system of objects giving a high-level description of printed mathematical expressions - this system should probably look like a straightforward translation of Content MathML into an object hierarchy. Objects should have a single method returning their representation in this system while the Printers have all the logic needed to create the print_* output. This would replace the _latex(), _mathml() methods as well as all the _print_Stuff() mess in printer classes and turn this (N object classes) * (M printers) problem into an (N+M) one. I don't know whether this representation should use sympy objects (= instances of Basic): avoiding the dependence on the rest of sympy could allow as a long-term goal to get other projects (matplotlib, ipython, ...) to use it, so that it becomes possible to exchange mathematical expressions with them without serialising to LaTeX or MathML. I don't know whether any of this can realistically be implemented any time soon but I think these are important medium-term goals that would make sympy more of a generic framework. -- 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.
