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).
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.
* 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?
Sebastian
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
