This looks very good so far. I have just some comments, which perhaps should be forked into another one of your mini-threads
- If you are planning on making any changes to the cache, you might want to take a look at bin/test -C and see what sorts of issues currently exist with it. There is also a caching label in the tracker. - Regarding Symbol('x', positive=True), I think this requires some thought. I am beginning to think that actually the best way to do this is to keep doing it like we do it now (modulo some refactoring of the Symbol class). I think perhaps there needs to be a separate set of global assumptions, which are assumptions that never change. For example, Q.positive(pi) (from my understanding this currently works by calling .evalf(); we should see if it's faster to do that or to store a bunch of Q.positive(pi) and so on explicitly, but anyway, not all custom object assumptions can be generalized like this) never changes, and so it should never be cleared, and additionally any facts resulting from it should never be cleared. In general, we want to allow objects to define their own assumptions about themselves, so that things can remain modular, and so that objects in user-land can work as first-class citizens with the assumptions. So, given that, I think that Symbol('x', positive=True) should be no different. This "keeps the assumptions in the core", but really, the issue is the inference code in the core. So I would just leave Symbol('x', positive=True) alone for now, and refactor how it works internally once we have a good API for how custom objects define their own assumptions on themselves. - It occurs to me that another advantage of using the "switch" method for switching over to the new assumptions is that it will become clear exactly what sorts of behaviors we are going to have to deprecate or completely remove, giving us an idea of the impact on users in the next release. Aaron Meurer On Sat, Apr 13, 2013 at 4:18 PM, Tom Bachmann <e_mc...@web.de> wrote: > Hi, > > I have spent the last couple of days writing up a more coherent proposal. It > is now in a readable state, see [1]. Any comments would be appreciated. (The > proposal is still slightly rough, in particular there are a few TODO notes, > and I haven't written anything yet about stretch goals.) > > Matthew: > I have not forgotten your email from april 10, > >> It might be nice to have a couple representative bugs/issues. What are >> the sorts of problems that we're facing? >> >> What is a specific piece of code that would break? >> What is an important routine that would run much more slowly? > > > I just have not had time do work out an answer, yet. > > Anyone else, if I have not addressed one of your concerns, please let me > know. > > Thanks, > Tom > > [1] > https://github.com/sympy/sympy/wiki/GSOC-2013-Application-Tom-Bachmann:-Removing-the-old-assumptions-module > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sympy+unsubscr...@googlegroups.com. > To post to this group, send email to sympy@googlegroups.com. > Visit this group at http://groups.google.com/group/sympy?hl=en-US. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out.