On Sunday, August 24, 2014 9:46:40 PM UTC+4, Aaron Meurer wrote: > > You make a good point. However, if you are going to spend time on this, it > would be better spent improving the new assumptions (and let's finally > merge my branch as a start to this), or merging the two. I still maintain > that this pull request is a step backwards. >
It's a much more difficult task then the simple pr in question. But I did some attempts in the past, see my branches assumptions-merge-new-old-DRAFT and assumptions-merge-new-old-DRAFT-REBASED (recent rebase). > With these changes, the new assumptions aren't used at all, meaning they > are tested much less, and more importantly, there is no more motivation to > improve them. > I don't think they are much tested now. For example, I have seen only one test failure after my modifications in the sets module. I fail to see reasons to keep such confusing code in the master. We should use one interface for the assumptions. In fact, this can simplify the mirgation too. The old assumptions syntax isn't going away, so why don't we focus on > making it so that the new assumptions can read the old assumptions. > > This is what @mrocklin and I attempted to do last summer ( > https://github.com/sympy/sympy/pull/2210). It didn't work, because we > tried to do a two-way merge of the assumptions, i.e., so that both > `x.is_integer` and `ask(Q.Integer(x))` were always identical (the logic I > used was https://github.com/sympy/sympy/pull/2210/files#r5463892, which > required both assumptions to be the same). > > Maybe an easier approach would be along the lines of what I have done at > #2508. Have ask call a bunch of things, in order, until it gets an answer. > In my branch, `ask` calls the current new assumptions, and then my satask. > We could make it so that ask first calls the old assumptions, then the new > assumptions. Furthermore, the new assumptions should gain trivial handlers > for Symbols to so that `ask(Q.real(Symbol('x', real=True)))` is True. > > The first step though will be to go through all the assumptions and make > sure they are identical in all systems. This is a good opportunity to clean > up some of the contradictory or unexpected assumptions, so it should > involve some community input. So I would do it on the mailing list. > > So I what I would recommend doing: > > - [ ] Merge my branch #2508. We can maybe wait until after the release to > do this so it is minimally disruptive, but this is important, as it will be > much easier to add new facts to the new assumptions with satask (and I also > want people to start thinking about how to improve the speed of it). > - [ ] Go through all the assumptions facts and make a note of what is > different, and also what is confusing. A lot of this is already written > down in various places (https://github.com/sympy/sympy/issues/5976, > https://github.com/sympy/sympy/pull/2538, probably some of the issues > mentioned in https://github.com/sympy/sympy/issues/6730, > https://github.com/sympy/sympy/pull/2508/files#diff-e0f95401c86d07d90903363122990de0R172, > > https://github.com/sympy/sympy/wiki/assumptions_handlers), but we should > gather them all down in one place. I think the main thing will be how we > handle infinity. > - [ ] Discuss with the community on the mailing list how we should handle > the differences, until we come to a consensus. > - [ ] Make the new assumptions call the old assumptions first. Also make > the handlers access the old assumptions, so that everything sees > `Symbol('x', real=True)` as real. This will be the hard part, and lead to > lots of test failures. It might be worth trying this first, to really see > what facts are different in the two systems. > > Note that absent from my plan is making `x.is_real` call the new > assumptions. This is what I tried at #2210, and it failed, because it > requires everything to work perfectly, and there are so many places that > the assumptions are used that it's too much work to get it all in one go. > We should get the above working first before we consider this. I don't > think there's a big issue with this, because already `ask(Q.real(x))` and > `x.is_real` are different. My proposal is to have the first call the second > but not the other way around. > > Aaron Meurer > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/d19cead7-0bcc-4377-a502-5f9780f49e41%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
