Thank you. Matching was the most annoying thing I encountered when working
with ODEs last summer. You can see some of the things that have had to be done
to work around it by looking at classify_ode() and related code in ode.py. For
example, it currently uses a helper function called _nth_linear_match() instead
of a match expression to match the general form of a linear ODE
(an(x)*f(x).diff(x, n) + … + a1(x)*f(x).diff(x) + a0(x)*f(x) = b(x) ), because
a match expression doesn't work (see commit
310debe9c0df76e0967c5efbc8d3fcd90bb0a5de).
On Apr 27, 2010, at 6:59 PM, Ronan Lamy wrote:
> Le mardi 27 avril 2010 à 15:49 -0700, basti a écrit :
>> Like many others before I stumbled over sympy's pattern matching. I'm
>> mainly interested in matching non-commutative expressions - which is
>> currently simply not implemented.
>> While starting implementing it I detected some shortcomings with sympy
>> which have to be solved first:
>>
>> (1) Inconvenient and surprising matching results (also for commutative
>> expressions).
>> (2) subs mechanism does not respect non-commutativity at all.
>> (3) subs does not allow evaluate=False as keyword
Non-commutativity is a mess and a big enough issue on its own.
>>
>> I will continue working on all three topics in the near future and
>> have already started (1) and (3).
>
> Cool! Can you share your code, even if it's not polished yet? (Just
> create a personal github repo, if you don't have one already and push
> your branch there)
>
>> Here are my plans so far:
>>
>> * Refactor whole matching logic into a separate module, and use the
>> Basic.match function only as interface. This was also done for
>> printing and I think the pattern matching is complex enough to justify
>> this step.
Yes, very good idea.
>
> I don't think it works so well for printing, having to hack into the
> printers every time you create a new class is annoying.
>
>> * Like maybe everyone else I have my own ideas what a pattern should
>> match and what not. It will be necessary to find some consensus. Maybe
>> we should start a Wiki page containing controversial matching examples
>> and everyone can give his opinion.
>> One example where I'm not happy with sympy's current behavior:
>>
>> In : (3*x**2).match(u*x/2)
>> Out: {u: 6*x}
>>
>> I think sympy is trying to be too clever here. I would like the
>> Mathematica behavior better where matching always requires structural
>> equivalence. I already implemented a pattern matching algorithm more
>> similar to this scheme, but of course it would mean work to convert
>> sympy to use this pattern matching and also the code of users might
>> have to be adapted.
>>
>> So I think it's mandatory to find some sort of agreement over how
>> pattern matching should be done first before changing the current
>> implementation.
>>
>> What does the rest of the sympy community think?
>>
> This issue has been raised many times and I think nobody likes the
> current situation. However, the current behaviour is quite convenient
> when it works, and much code depends on it. I think that the best
> solution is to distinguish structural matching (like Mathematica) from
> algebraic matching (like the current implementation of subs) and to have
> separate functions/methods for each.
>
Yes, this is the way to do it. Maple does it too. Maybe the algebraic subs
method could have a hints system similar to expand() so that you could turn off
things like x**3 matches x**2, but still get 3*x matches 2*x, and so on.
Aaron Meurer
> Some links you might find useful:
> * All the issues related to matching:
> http://code.google.com/p/sympy/issues/list?q=label:Matching
> * My own attempts to work on this:
> http://code.google.com/p/sympy/issues/detail?id=1736
>
> Ronan
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sy...@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sy...@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
