I am not sure what our symbol syntax would look like but something like:

Infinity() + ZeroOrMore(Any()) -> Infinity()
Infinity() + ZeroOrMore(I*Any(x_)) -> Infinity() +ZeroOrMore(I*Any(x_))

Part of what is needed priorities in the matching rules...

On Wed, Jul 3, 2013 at 12:49 PM, Aaron Meurer <[email protected]> wrote:
> So, how would you do my example, oo + 3 => oo, with pattern matching?
>
> Aaron Meurer
>
> On Wed, Jul 3, 2013 at 2: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
>>>
>>> etc.
>>>
>>> Summary - simple type based dispatch won't do - we need full blown pattern
>>> matching and transformation logic.
>>>
>>> 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.
>>>> >
>>>> >



-- 
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.


Reply via email to