Most of the problems with assumptions in SymPy are symptoms of larger
design problems which also affect performance, code clarity, and
customizability. The (semi-)new polynomial code, which supports
explicit coefficient rings (and term orders, etc), goes a long way to
address such issues, although its scope is limited.

For general symbolics, the analog would be to allow constructing
symbolic algebras, of which particular expressions would be elements
(compare with Parent/Element in Sage). Then simplification routines
would just be methods of the algebra class, and assumptions would be
properties attached to the algebra. For example, one could disable all
(or some) simplifications through subclassing. I'm almost convinced
that this is the cleanest object-oriented way to do it, since the
algebra would encapsulate all state and more.

Everything else is then just a matter of syntax (e.g. one can have
"global" assumptions by using a mutable global default algebra, and
one can have "local" assumptions by creating a local/temporary algebra
instance for this purpose). Caches could also be properties of
algebras. This would also allow algorithms to construct new algebras
for internal use,  use any assumptions, caching, etc., and be sure
that this wouldn't have an effect on the outside world.

I did a similar thing with the "contexts" in mpmath, although I didn't
really go all the way (creating multiple instances of the same context
class is still a bit flaky, and doesn't work in Sage, but the fp and
iv contexts show how powerful this approach is). This helped
*tremendously* with writing the Cython backend in Sage, anyhow.

Fredrik

-- 
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.

Reply via email to