On Wed, Jul 3, 2013 at 4: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... > >> >> >> To answer Aaron's question: >> >> On Wed, Jul 3, 2013 at 12:58 PM, Aaron Meurer <[email protected]> wrote: >>> So, going back to what we discussed the first time we met in Los >>> Alamos, how would you reimplement something like the oo logic so that >>> it lives entirely in the Infinity class, not in Add.flatten (say for >>> simplicity, oo + 3 should go to oo, but oo + 3*I should remain as oo + >>> 3*I)? >> >> This, and another example is x + O(x). Let's stick to oo + 3. >> >> This is a very good question and it is one of the details that I don't >> know the answer 100% yet. >> But I feel it is solvable. >> >> The general idea is that you create a new type, let's say Infinity and >> register mul, add, div, sub, pow using dispatch, which specify how >> your new type should be handled. >> >> In particular, it would look something like: >> >> @dispatch(Infinity, Basic) >> def mul(a, b): >> if isinstance(b, Integer): >> return a >> else: >> return Add(a, b) > > But Mul is not a binary operator in SymPy - we could make it so and > build the overall *args version by repeatedly calling the binary > version. That would be nice... and would somewhat help our > situation...
I don't think that magically solves the problem. It just changes the form of it (and not in a particularly useful way in my opinion). The issue is that you need for something like oo + I + 3 to work, where the oo and the 3 are not next to one another. With your idea, it would be represented as (oo + I) + 3 (or maybe oo + (I + 3)). In either case, you have to add a complicated rule to dispatch against an Add, which checks all the arguments. And by the way, if you're shy on examples, just look at that wiki page. There are even more that aren't on there. Aaron Meurer > >> This covers most usecases for "oo", since when you construct it in >> Python, you always use the two argument mul(a, b). Also when Add is >> constructed, the algorithm simply takes one term at a time and "adds" >> it to what is in Add already. So those are all binary operations that >> could be overridden in principle. >> >> For example a faster core might decide for speed reasons to not allow >> "oo" and O(x) terms. Then multiple dispatch would pretty much make >> sure that either the fast core will be used if you do add(x, y), but >> slow and more general sympy core will be used if you do add(x, oo). >> >> >> I think the best would be to create a demo (from scratch) where we can >> play with these ideas. Hopefully I'll get to this eventually. >> >> Ondrej >> >>>> >>>> Cheers, >>>> >>>> Brian >>>> >>>> >>>> On Wednesday, July 3, 2013 10:27:19 AM UTC-7, Aaron Meurer wrote: >>>>> >>>>> No, Add(x, y, z, t) is not just used for fast construction. Any >>>>> algorithm that recurses through an expression tree and rebuilds things >>>>> will rebuild an Add in that way, using expr.func(*expr.args). >>>>> >>>>> Aaron Meurer >>>>> >>>>> On Wed, Jul 3, 2013 at 12:22 PM, Ondřej Čertík <[email protected]> >>>>> wrote: >>>>> > On Wed, Jul 3, 2013 at 11:15 AM, Aaron Meurer <[email protected]> wrote: >>>>> >> I don't think it's so easy, because Add has *args. >>>>> > >>>>> > If you are talking about things like: >>>>> > >>>>> > In [2]: Add(x, x, x, y, x, x) >>>>> > Out[2]: 5⋅x + y >>>>> > >>>>> > Then those are of course needed for fast construction many terms into >>>>> > on Add, but this not really exposed to user's code and it is used >>>>> > inside things like expand(). As such, we can provide a special static >>>>> > method or function for doing the same. On the other hand, if you >>>>> > write: >>>>> > >>>>> > x + x + x + y + x + x >>>>> > >>>>> > in Python, then Python itself will call Symbol.__add__ etc., so this >>>>> > would work well with our new dispatch. >>>>> > >>>>> > -- >>>>> > 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. >>>>> > >>>>> > >>> >>> -- >>> 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. >>> >>> >> >> -- >> 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. >> >> > > > > -- > Brian E. Granger > Cal Poly State University, San Luis Obispo > [email protected] and [email protected] > > -- > 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. > > -- 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.
