[sympy] Re: Future plans for pattern matching

2010-05-03 Thread Vinzent Steinberg
On 2 mai, 19:58, "Aaron S. Meurer" wrote: > For pattern matching where the result is not well defined, what do you plan > to do (e.g., (x + y).match(u + v), u and v are both Wild's)?  Will you just > have a disclaimer that if you do this, the result could be not what you > expect? We could add

[sympy] Re: Future plans for pattern matching

2010-05-03 Thread smichr
Sebastian wrote: (1) Implement a generic "Hint"s model which can be used to store values of different hints and also be used to find out interactively what hints are possible. (This is already done in the hints branch and might also be useful for other parts in sympy) I have a manage_hints routin

[sympy] Re: Future plans for pattern matching

2010-05-04 Thread Sebastian
Thank's for pointing this out! Arron already mentioned it and I had a look on it but I think it's maybe a bit too limited for general usage. I wrote up my ideas of a hinting model in the branch "hints" on my github repo: http://github.com/bastikr/sympy/tree/hints You can pull it and build the docum

[sympy] Re: Future plans for pattern matching

2010-05-04 Thread Vinzent Steinberg
On May 3, 10:11 pm, Sebastian wrote: > The implementation of subs and match by itself will be much easier to do > without worrying about the old code and having to ensure after every > commit that the old and the new algorithm interact perfectly. The > question is if the final merging is then that

[sympy] Re: Future plans for pattern matching

2010-05-07 Thread smichr
> Of Chris's stuff, I like some of the shortcuts he has implemented that reduce > typing for more complex hints.  Sebastian's writeup doesn't mention some of > the key things, like the logic for what turns other hints on and off (I am > assuming this would all go in the HintManager).   I can qu

[sympy] Re: Future plans for pattern matching

2010-05-08 Thread Vinzent Steinberg
On 7 Mai, 23:51, "Aaron S. Meurer" wrote: > Another possibility would be to somehow take advantage of *args, which is > ordered. What about expand('mul', 'trig')? Vinzent -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send e

[sympy] Re: Future plans for pattern matching

2010-05-08 Thread smichr
On May 8, 5:37 pm, Vinzent Steinberg wrote: > On 7 Mai, 23:51, "Aaron S. Meurer" wrote: > > > Another possibility would be to somehow take advantage of *args, which is > > ordered. > > What about expand('mul', 'trig')? This works if you just want hints that should be on, but you would have to

[sympy] Re: Future plans for pattern matching

2010-05-13 Thread William Ratcliff
Any thoughts on speed? When we have REALLY long expressions, we find that subs (and collect) can both run rather slow. We're interested in contributing to increasing their speed for common use cases... Cheers, William On May 8, 8:37 am, Vinzent Steinberg wrote: > On 7 Mai, 23:51, "Aaron S. Me

[sympy] Re: Future plans for pattern matching

2010-05-13 Thread Sebastian
Yes, I definitely think it should be possible to make things faster: * Don't rebuild expressions if nothing is substituted. In the moment all expressions are rebuild every time. (I think this is somehow mended by cashing). * Parallel substitutions. If more than one pattern should be substituted i

Re: [sympy] Re: Future plans for pattern matching

2010-05-06 Thread Aaron S. Meurer
I think that both have their benefits. I like how Sebastian's model makes hints objects, which means that they can have docstrings and can be callable. I also like having the hint manager be and object, and the decorator idea. Of Chris's stuff, I like some of the shortcuts he has implemented t

Re: [sympy] Re: Future plans for pattern matching

2010-05-07 Thread Sebastian
On 05/07/2010 02:57 PM, smichr wrote: >> Of Chris's stuff, I like some of the shortcuts he has implemented that >> reduce typing for more complex hints. Sebastian's writeup doesn't mention >> some of the key things, like the logic for what turns other hints on and off >> (I am assuming this wou

Re: [sympy] Re: Future plans for pattern matching

2010-05-07 Thread Sebastian
On 05/06/2010 03:35 PM, Aaron S. Meurer wrote: > I think that both have their benefits. I like how Sebastian's model makes > hints objects, which means that they can have docstrings and can be callable. > I also like having the hint manager be and object, and the decorator idea. > > Of Chris's

Re: [sympy] Re: Future plans for pattern matching

2010-05-07 Thread Aaron S. Meurer
On May 7, 2010, at 2:44 PM, Sebastian wrote: > On 05/07/2010 02:57 PM, smichr wrote: >>> Of Chris's stuff, I like some of the shortcuts he has implemented that >>> reduce typing for more complex hints. Sebastian's writeup doesn't mention >>> some of the key things, like the logic for what turn

Re: [sympy] Re: Future plans for pattern matching

2010-05-07 Thread Sebastian
On 05/07/2010 11:31 PM, Aaron S. Meurer wrote: > On May 7, 2010, at 2:44 PM, Sebastian wrote: > > >> On 05/07/2010 02:57 PM, smichr wrote: >> Of Chris's stuff, I like some of the shortcuts he has implemented that reduce typing for more complex hints. Sebastian's writeup doesn't

Re: [sympy] Re: Future plans for pattern matching

2010-05-07 Thread Aaron S. Meurer
On May 7, 2010, at 3:47 PM, Sebastian wrote: > On 05/07/2010 11:31 PM, Aaron S. Meurer wrote: >> On May 7, 2010, at 2:44 PM, Sebastian wrote: >> >> >>> On 05/07/2010 02:57 PM, smichr wrote: >>> > Of Chris's stuff, I like some of the shortcuts he has implemented that > reduce typing fo

Re: [sympy] Re: Future plans for pattern matching

2010-05-08 Thread Aaron S. Meurer
It could work if the hints are callable objects as Sebastian suggests, though you would have to first dig up the objects in order to call them. Aaron Meurer On May 8, 2010, at 7:43 AM, smichr wrote: > > > On May 8, 5:37 pm, Vinzent Steinberg > wrote: >> On 7 Mai, 23:51, "Aaron S. Meurer" wro