On Wed, Aug 29, 2012 at 1:36 AM, Juha Jeronen <[email protected]> wrote: > On 28/08/12 20:45, Aaron Meurer wrote: > > On Aug 28, 2012, at 5:07 AM, Juha Jeronen <[email protected]> wrote: > > ---8<---[snip]---8<--- > > > In conclusion, rcollect() and my suggested code do different things, so I > would still like to request consideration for whether the new functionality > would be useful in standard SymPy. > > > Based on this, I'd say the functions would be useful. Any thoughts on where > it should go? Maybe collect (or rcollect) with no symbols given would use > this. > > > Thanks for the input. > > I think the functionality should be split into two parts: > > > 1) The automatic symbol list generation. This could be used as a default for > collect() and rcollect(), if no symbols are given. > > In the case of rcollect(), the list should probably be generated at each > level of recursion separately to achieve optimal collection (consider e.g. > "c*a*(b*x + b*y) + c*b*(a*x + a*y)"). > > I think the symbol list generator could also be exposed in the API, as there > might be some unanticipated uses for it.
Is this different from .free_symbols? > > > 2) The two ways of recursive collection: current rcollect() vs. the > suggested code. There may be cases where either of them is preferable, so I > think both are needed. > > In my opinion, the most logical place for this part of the new functionality > would be rcollect(). Should we add a flag for choosing the mode? But which > mode should be the default? (This is not exactly "deep" vs. "non-deep", but > different recursion strategies.) > > Or should we add a new API function, keeping rcollect() as-is? This solution > doesn't seem very clean. Well, I actually would like to have just one function, collect(), but that would require changing the API. So I would try to find a good name for each strategy, and use method="name" in rcollect(). As to what should be the default, I don't know. And as I said, the automatic symbols can happen if no symbols are given. > > > > > And finally, about rcollect(): > > - Is there a reason why the call syntax differs from collect()? collect() > takes in a list of syms, while rcollect() uses Python's *args mechanism for > the same (and calls them "vars", instead of "syms" like collect()). > > - Suggestion for documentation: rcollect() could be mentioned in the > documentation for collect() to make it easier to find. At least I find it a > bit confusing that many of the other simplifiers come with a "deep" flag, > but for collect() the recursive version is a separate function. (Of course, > technically there is the distinction of descending into function arguments > vs. recursing into sums, so the difference may be justified.) > > > These are valid points. We try to be consistent with our APIs, but > unfortunately sometimes people either don't know or forget the conventions > when contributing code. > > > I see. Well, that's understandable :) By the way, it's not so bad that one is called vars and the other syms, but the thing that is bad is that one is *vars and the other is syms. So one takes a list and the other doesn't. Aaron Meurer > > > > Perhaps we should start a little API style guide somewhere for those things > that have already become conventions in the SymPy API, like use of the word > "deep". > > > Hmm, this sounds a good idea. > > > -J > > -- > 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. -- 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.
