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