On Wed, Apr 10, 2013 at 1:47 PM, Tom Bachmann <[email protected]> wrote: > On 10.04.2013 20:27, Aaron Meurer wrote: >> >> One thing that I think hasn't been mentioned yet is that we do still >> want x.is_foo to work, and probably Symbol('x', foo=True) as well. >> .is_foo is way easier to type than ask(Q.foo(x)), and there are tons >> of lines of code that use this idiom, both in the SymPy library and in >> user code. >> > > I was under the assumption that is_foo is expected to remain. Once we have > transitioned to new assumptions, this would simply turn into a wrapper for > ask(Q.is_foo(self)) [using only global assumptions], wouldn't it. > > >> For Symbol('x', real=True), we need to decide exactly how we are going >> to handle global assumptions. >> > > Hm. I understand that for backwards compatiblity we will want this to remain > working, at least some time. > > This seems reasonably easy to achieve with the new assumptions system (at > least in principle): Symbols keep storing these extra assumptions, and > equality-comparison remains as it is. The Symbol constructor injects the > assumptions into global_assumptions. > > This way > > Symbol('x') # no assumptions > Symbol('x', positive=True) # actually secretly a different object! > Symbol('x') == Symbol('x') # True > Symbol('x', positive=True) == Symbol('x', positive=True) # True > Symbol('x') != Symbol('x', positive=True) # True, as currently > Symbol('x', negative=True) # No contradictory global assumptions! > > Of course, if we were to go with the .assumptions field, then this is not > really an issue. > > >> But assuming this, why can't we just transition by making these two >> things work in the new assumptions, then switching the flag in Basic >> to use the new assumptions instead of the old ones. We will then get a >> ton of bugs and performance issues, which should then be fixed. >> > > "the flag" - is there already one?
No, I meant one that you were describing. There would be somewhere in the core that has if NEW_ASSUMPTIONS make is_foo and Symbol(foo=True) call the new assumptions else: do what we are doing now This actually is only necessary if the new assumptions are really problematic. We should try just doing it, and running the tests, and seeing what happens. If it's a lot of work, then we can add the flag so that you can push it into master and fix the issues with pull requests. Then, once all the issues are fixed, we remove the flag (and all the old assumptions). This whole process should happen entirely in the development repo between releases. I guess changing other code to work simultaneously with both old and new assumptions is not easy, so we should either fix everything at once, or put similar wrappers in the code there too. The only purpose of the flag is to allow us to fix the issues in pieces without the work getting stale in a pull request. If there aren't that many issues, we shouldn't even do it. At the end, it will be easy to remove the old assumptions by just removing all the "else" clauses throughout the code base. Aaron Meurer > > But more importantly, at what point *do* we fix the "ton of bugs and > performance issues"? Surely we do not want a broken master? > > >> Aaron Meurer >> >> On Wed, Apr 10, 2013 at 10:46 AM, Brian Granger<[email protected]> >> wrote: >>> >>> I am strongly -1 on having the new assumption logic in master but >>> disabled globally with flags. >>> >>> On Wed, Apr 10, 2013 at 9:20 AM, Matthew Rocklin<[email protected]> >>> wrote: >>>> >>>> I think you would traverse the input expression tree once to collect all >>>> assumptions stored in that tree into a set. You would then use that set >>>> during the computation (maybe this goes into ask?). Probably a tree >>>> would >>>> cache its set of assumptions after the first traversal. In what case >>>> would >>>> facts change during a computation/query? >>>> >>>> It doesn't strike me as the slow part of assumptions. In any case it's >>>> something that you could slowly remove as code developed - fewer and >>>> fewer >>>> bits of code would depend on the assumptions field. >>>> >>>> But I don't like this idea anyway. I mostly don't like the idea of >>>> adding >>>> an extra field to Basic. It makes it substantially less basic. >>>> >>>> >>>> On Wed, Apr 10, 2013 at 11:01 AM, Tom Bachmann<[email protected]> wrote: >>>>> >>>>> >>>>> On 10.04.2013 16:56, Matthew Rocklin wrote: >>>>>> >>>>>> >>>>>> Old and new assumptions differ in a few ways. >>>>>> >>>>>> 1. They store assumptions in different places (this is the main issue >>>>>> here I think) >>>>>> 2. They represent assumptions differently >>>>>> 3. They represent relations differently >>>>>> 4. They infer/compute differently >>>>>> >>>>>> I don't particularly like this idea, but one could consider a solution >>>>>> that changes 2,3,4 but doesn't change 1. Alongside the .args tuple, >>>>>> Basic could also hold an .assumptions frozenset as a field. >>>>>> Computations that use assumptions could then check both the global >>>>>> collection and all assumptions in the expression tree. This might be >>>>>> an >>>>>> intermediate step in our development. >>>>>> >>>>> >>>>> I thought about that, but it is not obvious how to make it work. I >>>>> suppose >>>>> you would need to take the transitive closure of all assumptions. I.e.: >>>>> >>>>> - take all facts, extract all symbols into a list L >>>>> -0append the symbols in the expression being queried to L >>>>> -for every object in L, read out the assumptions frozenset, and append >>>>> it >>>>> to facts >>>>> - start over if the facts have changed >>>>> >>>>> This seems potentially quite slow. >>>>> >>>>> >>>>> -- >>>>> 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 [email protected]. >>>>> To post to this group, send email to [email protected]. >>>>> 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 [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at http://groups.google.com/group/sympy?hl=en-US. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>>> >>> >>> >>> >>> -- >>> Brian E. Granger >>> Cal Poly State University, San Luis Obispo >>> [email protected] and [email protected] >>> >>> -- >>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out.
