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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
