There are some good ideas here. See my comments below. I have responded to
both Brian and Ronan.
On Feb 15, 2011, at 9:17 PM, Brian Granger wrote:
> 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?
I think having objects for all the sets (or sets with structures) is another
common thing that other CASs do. Again, we should look at how the better, more
mature ones out there do it.
Also, this makes me realize that this is related to assumptions. How would you
recommend having the assumptions with respect to this system?
> * 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.
Isn't coercion implicit while casting is explicit? At least that's what the
names imply to me. Anyway, if it is, we might remember that "explicit is
better than implicit."
> * 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…
This all sounds good. We should look at what other, more mature computer
algebra systems do with this.
It sounds to me like it might require a pretty significant rewrite of the core.
I think that if we ever do decide to make such a change, that we should try to
make the core as modular as possible, so that we can avoid future rewrites.
>>
>> 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.
I understand mathematically the difference between the two, but I don't see
from your explanation how you think they should be different in SymPy.
Anyway, the name "symbol" is pretty engrained in SymPy by now, so if you are
suggesting a name change, I don't think that would be possible.
>>
>> 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.
Brian makes a good point. Why do we need what would essentially be a separate
implementation of the core to do printing. The representation for an object can
just be the object itself. This wouldn't, as you say, make it very easy to
adapt to other systems, but I think it would be the easiest to work with from
within SymPy itself.
>
>> 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.
This is another thing. For an arbitrary printer, you might need any amount of
information contained in the original object. Or maybe you will say that the
code printer shouldn't really be implemented as a printer.
Aaron Meurer
>
>> 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.
