On Friday, July 4, 2014 9:14:29 PM UTC, Joachim Durchholz wrote: > > Am 03.07.2014 21:39, schrieb F. B.: > > I updated the draft: > > > > https://github.com/sympy/sympy/wiki/Proposal-for-a-new-pattern-matching > > The page uses the term "unification" without defining it. > Given that there are multiple variants of unification, some of them even > Turing-complete, the term should be either defined or replaced with a > different one. > (E.g. my experience with unification is from Prolog, which does deep > structural matching and wildcards, among other things. Which is clearly > not what's meant in the draft.) >
I meant unification as the one in the library by Matthew, i.e. expressions that have both wildcards and a substitution is found such that the two expressions become the same. I don't think that unification is good in case of subtree matching, because it would become very ambiguous. Mathematica's pattern matching just tries to identify a subexpression and acts on it. The mathematical expressions users work with do not usually contain wildcards, I think that wildcards should be treated only when they are in the pattern. > > rewrite should always update the counter. It's a cheap operation, and > having rewrite *and* rewrite_with_counter is just going to complicate > the API with little benefit. > First get it right, then get it fast. And don't worry too much about > speed in the detail if you can still optimize the algorithms. > > Yes, that was just a draft. It can be rethought. > I agree it would be nice to be able to explore the different ways to > apply matches. > All of SymPy's matchers so far were concerned in matching the whole expression. A user may have a huge expression, and be willing to apply a rewriterule to only some parts of it, that's why we need subtree matching. > However, a "next" variant is probably going to be meaningless, you might > end up testing a gazillion of associativity-equivalent subexpressions > while deep, deep inside there's an integral that might become solvable > with the right transformation applied. > I.e. exploring the space of transformation/substitution variants isn't > going to be a good match for a linear order. > I'm not even sure that one could even sort substitutions by relevance, > different people might consider different substitutions relevant. > We have all source code of Mathics available on github, which is a clone of Wolfram Mathematica. I would keep compatibility with the sorting established by Mathematica. Consider the possible advantage of easily importing open source Mathematica libraries into SymPy or into Python. Exhaustive replacement needs a limit. Anything that can do the natural > number axioms is Turing-complete, and I bet the substitution rules are > at least as powerful as the natural number axioms. > By exhaustive replacement I meant something similar to this: http://reference.wolfram.com/mathematica/ref/ReplaceRepeated.html > For the API: Have you considered a chaining style? (a.k.a. "fluent > style" or "DSL" - the terms aren't equivalent but often go together.) > With the API as proposed, things are going to be pretty deeply nested, > and that tends to be rather hard to read. > I am not very happy with this API, so any other proposals are welcome. An other idea I had, is to use ordinary expressions with no wild objects, and recognize symbols as wilds if they have a trailing underscore "_" sign. This is the way Mathematica works. Not sure how these obervations can be included, the coding might already > be ahead of the issues I'm raising (and I'm not sure how relevant they > are anyway). > There is no coding yet, this is just a proposal. -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/0930d7be-e6c1-472a-9a2c-3d7586a5197e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
