On 28/08/12 20:45, Aaron Meurer wrote: > On Aug 28, 2012, at 5:07 AM, Juha Jeronen <[email protected] > <mailto:[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. 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. >> 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 :) > 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.
