Such kind of project can be helpful in making students understand programming skills and giving them knowledge for basic mathematical problems It can be also helpful for the Professors for teaching.
On Wed, Feb 15, 2012 at 10: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.) > > > > 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. > > 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+unsubscribe@** > googlegroups.com <sympy%2bunsubscr...@googlegroups.com>. > For more options, visit this group at http://groups.google.com/** > group/sympy?hl=en <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.
