On Wed, Jul 3, 2013 at 3:46 PM, Brian Granger <[email protected]> wrote: > On Wed, Jul 3, 2013 at 2:42 PM, Ondřej Čertík <[email protected]> wrote: >> On Wed, Jul 3, 2013 at 3:19 PM, Brian Granger <[email protected]> wrote: >>> On Wed, Jul 3, 2013 at 1:42 PM, Ondřej Čertík <[email protected]> >>> wrote: >>>> On Wed, Jul 3, 2013 at 1:48 PM, Aaron Meurer <[email protected]> wrote: >>>>> Brian, I think you dropped off list. Forwarding to sympy. >>>>> >>>>> Aaron Meurer >>>>> >>>>> On Wed, Jul 3, 2013 at 2:29 PM, Brian Granger <[email protected]> wrote: >>>>>> I think that having multiple dispatch is something that is needed within >>>>>> SymPy. Multiple people have run into the difficulties with providing >>>>>> custom >>>>>> Add/Mul logic for their new types. In quantum, we just punted and used >>>>>> the >>>>>> builtin Add/Mul logic, but it was a bad compromise to make. >>>>>> >>>>>> For this, I think looking at Mathematica is really important. This is >>>>>> handled by Mathematica's Rules and Patterns which are documented here: >>>>>> >>>>>> http://reference.wolfram.com/mathematica/guide/RulesAndPatterns.html >>>>>> http://reference.wolfram.com/mathematica/tutorial/Introduction-Patterns.html >>>>>> >>>>>> If we don't have first class, nested and general pattern matching, we >>>>>> can't >>>>>> do multiple dispatch. The case in point is classes that accept *args >>>>>> such >>>>>> as Add and Mul. Good fast pattern matching would also allow us to do >>>>>> much >>>>>> of the logic in Add/Mul constructors using patterns: >>>>>> >>>>>> Add(x_, x_) -> 2*x_ >>>>>> Mul(x_, x_) -> x**2 >>>> >>>> Pattern matching is another way to implement CAS, but I am actually not >>>> sure this is how Mathematica works inside. Also in pure Python, this might >>>> be really slow (I don't know). I don't see all the little details for >>>> pattern matching >>>> approach. I think I can see more of the details for the sympy approach >>>> though. >>>> >>>>>> >>>>>> etc. >>>>>> >>>>>> Summary - simple type based dispatch won't do - we need full blown >>>>>> pattern >>>>>> matching and transformation logic. >>>> >>>> Why wouldn't simple type based dispatch work? >>>> You might be right, I just want to understand the problem more. >>> >>> For example take a quantum time evolution operator exp(-I*t*H). What >>> if I wanted to develop custom logic for that operator. Simply >>> matching on type type (exp) won't work. You need to be able to say: >>> >>> exp(-I*Numer(x_)*HermitianOperator(y_)) >>> >>> That requires pattern matching... >> >> So first of all, since H does not commute, H will not be a Symbol, but >> rather an NCSymbol. >> Then the "*" in there will not be Mul but NCMul, thanks to our binary >> dispatch. >> exp can in principle be NCFunction or something. > > But that is besides the point - there are infinitely other examples > where you need to apply pattern matching logic that is not merely type > based.
Ok, can you give me another one? > >> What kind of custom logic are you thinking of? The automatic canonical >> simplification should only be very simple things, most probably in >> this case just things that NCMul can do. > > I am thinking that the automatic canonical simplification logic > everywhere in sympy would be replaced by rules+patterns. > >> Anything more advanced (like perturbation expansion of "exp") should >> be implemented as an extra function. > > I completely agree... This extra function can use pattern matching, that's fine. So we are talking about very minimal canonical simplification, like H-H ->0, but H*A - A*H stays intact. I think that two main cases are commutative and non-commutative symbols. This covers 95% of cases. Both should be in sympy itself. For the rest you need to create a special type and dispatch. Maybe it is possible to implement pattern matching efficiently, but I am a bit skeptical. The dispatch based on just types on the other hand should be fast. Ondrej -- 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.
