On Wed, Feb 15, 2012 at 11:20 AM, Joachim Durchholz <j...@durchholz.org> wrote: > Am 15.02.2012 02:14, schrieb Aaron Meurer: > >> The question is what would be a good interface for this? > > > Probably some tree transformation framework. > That way, the transformation steps exist as objects and can be displayed, > inspected, possibly varied etc. > > And yes that would be sweet. In particular, if a formula gets > mistransformed, it would allow the user in question to pinpoint the > transformation that's in error, so people without a deep understanding of > the math behind some transformations could fix simple bugs. > (Right now, I wouldn't touch e.g. integral transformation. I have enough > math background to check the validity of some transformation, given a pile > of paper and a free weekend; I couldn't judge strategy. If the math were > separated from the Python mechanics, I could still work on the mechanics if > there's a bug in it.)
Well, the more advanced algorithms would still be used when relevant. In that case, only the simple cases implemented here would be available. For example, if you enter a non-trivial integral into WolframAlpha, or any integral requiring techniques beyond taking anti-derivatives to compute (e.g., using residues), it does not show the steps, because it uses the more advanced algorithms that do not translate into steps. > > >> For the most >> >> part, it would probably mean reimplementing the basic "by hand" >> algorithms, so that you can determine exactly what steps are used. > > > Definitely. > > >> What should the output look like, so that it is both readable and >> usable (e.g., maybe some kind of annotated objects representing >> operations that you can literally apply to an expression to do those >> things). > > > Have some way to specify transformation rules that work on an expression > tree. > It shouldn't be hard to represent these something like this: > > a * (b + c) ---> a * b + a * c > > We might even be able to use standard SymPy formula rendering; the only new > symbol would be the "transforms to" symbol, rendered as ---> in the example > above. > > Rules should be associated with overall goals. > E.g. for boolean expressions, the goal could be conjunctive normal form, > disjunctive normal form, or minimum number of operators (the one you'd set > up a Karnaugh table for). You'd want different rules active depending on the > goal here. > Similar representational variations exist for sums of fractions. > > Goals might work better if they can be restricted to a part of an > expression. > It might also be an idea to give each goal a weight; that way, users can > specify conflicting goals and let the transformation engine choose the > combination of goals that gives the best results. However, that's an area > for heuristics, so it's probably a good idea to review the literature > available on the subject. > > Relevant key terms would be "term rewriting" and "tree transformation". > > The nice thing is that it can be done incrementally: Have a basic tree > transformer in place, then gradually replace existing transformation code > with rule usage. > > >> Another question: for those operations where what SymPy does is pretty >> close to what you'd do by hand (e.g., differentiation), what is a good >> way to avoid code duplication and make things extensible? > > > I think the existing code would get replaced by rules. > You don't want to chase inconsistencies between transformation code and > rules. I guess it would depend on how they compare in performance and power. Aaron Meurer > > Just my 2c. > > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to sympy@googlegroups.com. > To unsubscribe from this group, send email to > sympy+unsubscr...@googlegroups.com. > 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 sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
