Ronan,
> 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.
Yes, these issues came up for us a lot in the writing of the quantum
stuff. For examples, we currently make the implicit (and possibly
false) assumption that commutative=False means that something is an
Operator. But, of course, you can easily have non-commutative things
other than Operators.
> 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.
Yes, absolutely. Having a proper mathematical type system would allow
us to easily do validation of various operations. We definitely need
this in quantum, where, for example, we can do lots of mathematically
insane things like 2 + Ket('psi').
> 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.
I think the basics of this idea are great. Some questions though...
* For mathematical objects, it seems like there are two broad types of
things: spaces and things that live in those spaces (elements). There
are vectors and vector spaces, Kets and hilbert spaces, the ring of
integers, etc. Do we also need to think about objects that encode the
spaces as well as the elements they contain?
* Coercion. Sage has thought through this type of thing in
considerable depth and one conecpt they have is coercion. I don't
quite understand the difference (in Sage) between casting and
coercion, but the general idea is what do you do when you attempt an
operation between two different types - how do you coerse one type
into another so that the operation can happen.
* Are the interfaces you envision on the type objects or the objects
that have the type attributes? Does that make sense?
> 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.
I think the extensibilty of sympy is super important - it is one of
the most attractive parts of it. The quantum stuff we did would have
been very difficult in many other environments, but having a proper
type system would make it even easier and more robust.
> 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.
So are you thinking that a variable is a symbol that has a definite type?
> 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/...
The only issue with this is that in many cases the abstract notion of
how something is printed is very dependent on the features of the
printer. For example, in the quantum stuff for printers that have
subscripts (pretty, latex, etc.) we do one thing, but for printers
with no good looking subscripts, something completely different. Thus
is may be difficult to abstract this in a clean way.
> 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.
Also, our notion of printers is much more general than mathematica
notation. Some of our printers output code, which is *very* different
from mathml or latex as a base.
> 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.
I think the first two of these proposals are quite interesting. The
third, possibly, but it is not clear how it would all work.
Cheers,
Brian
>
> --
> 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.
>
>
--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
[email protected]
[email protected]
--
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.
