> I see some potential issues with this. First is that depending on how > you define a match, you might have infinitely many possible results. > For examples, (x**n).match(p*q) might give x**n*1 or x**(n - 1)*x or > (x**n*a)*(1/a) or x**(n - a)*x**a (for arbitrary a). The third one in > particular sounds a little contrived, but consider if we had a*x**2 + > x, and we wanted to match against p*q, where q excludes x. We might > want that to give a*(x**2 + x/a). So it's not too far off to consider > "adding a new term" to a multiplication. > > So it's clear that to do this, you need to make sure that the matching > is very precisely defined. Probably in an AST way more than a > mathematical way (but not necessarily). Another issue might be that > all possible matches might be large, possibly even combinatorially > large, depending on what your expression is. > > With that being said, I think this is a good idea, and that you should > explore it. >
Yes, I'm more interested in structural matching. After reading more about this I think I'm actually interested in Unification. I'm not interested right now in mixing matching with mathematical transformations. I think that's likely to be a harder problem. Regarding combinatorial explosion yes, that's an issue. There are a few ways to get past this, the first is to do this whole experiment with lazy generators. Get one match quickly, ask for another if you don't like it, if you want all of them you have that option. I believe that Prolog works this way. You might also be able to do some sort of guided search. Ideally we find a way to separate the search mechanism from the matching. -- 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.
